Lock cube from read operation followed by a write operation

[winsonlee]

http://www-01.ibm.com/support/docview.w ... wg21460595

Parallel Interaction impact on ‘TM1 Semaphore’ Best Practice
Prior to TM1 9.5.2, customers employed a Turbo Integrator Best Practice called ‘Semaphore’ to prevent TI ‘thrashing’ (successive rollbacks and retries) which resulted from concurrent execution of TI’s that locked the same objects and blocked each other.

For instance, an end user data input Websheet contains an Action Button that calls a TI to copy data from input cubes to a reporting cube. This use case may result in concurrent execution of a TI process that performs a read operation followed by a write operation. During periods of high concurrency, the write operation may encounter a locked cube (as a result of another write operation), causing the TI to rollback its work, and re-initiate the process. Subsequent ‘re-tries’ by the TI may also encounter a locked destination cube, causing another rollback - a wasteful situation known as ‘thrashing’- which results in performance issues for the end users.

The ‘TM1 Semaphore’ Best Practice approach calls for the TI’s to update a common cube in the prolog section to ‘register’ themselves for execution – knowing that if they held the lock on the semaphore cube, they would execute to completion without concern for locks by concurrently run TIs. If the attempt to write to the common cube in the Prolog encountered a lock, the rollback time would have a minimal impact on performance. With Parallel Interaction, concurrent writes to the semaphore cube will not cause serialization – all writes occur in parallel!

With TM1 9.5.2 PI, the ‘TM1 Semaphore’ Best Practice as described above may not be needed or may need to be adjusted to ensure a similar behavior. If the TI is only reading and writing data – the TM1 Semaphore approach is no longer needed to achieve better performance. In this case the concurrent TIs will run to completion with no locking behavior.

If the TI is performing Meta Data maintenance – a new semaphore approach may be needed to ensure the TI doesn’t thrash. Performing maintenance to a common dimension might be a suitable alternative. The Best Practice for using a dimension as a semaphore controlling object is to have your Base TI call a dimension semaphore TI using Execute Process in the Prolog tab. The Dimension Semaphore TI shall simply insert a dummy element in the controlling dimension, thereby locking that dimension so no other TI that maintains that dimension can proceed. The Base TI shall then remove the dummy element in the Epilog tab.

I need to copy data from a view and put in into a cube. It is a very large cube and at the moment I am just reading data from the view and use cellputN to write data to the cube and it is taking a very long time. The IBM website mention that it may be due to lock cube. On the website it mention that to prevent this issue from happening, we can adopt the ‘Semaphore’ approach to prevent TI ‘thrashing’. can someone gives me some guide lines on how this can be achieve ? For your info i am using Tm1 9.4.1 but will be upgrading to 9.5.1 soon. So in either of the version if I am able to get the semaphore to work, it will be great.

[Andy Key]

http://www.tm1forum.com/viewtopic.php?f=3&t=3913 should give you some pointers.

[winsonlee]

the Semaphore approach is it the solution to multiple user is running the same process at the same time and it causes lock cube ?

my scenario is more like one process is running and it reads the data from the cube and writes the data back to the cube. so it is a continues read and write when the process is executed. will that cause TI ‘thrashing’ ?

[lotsaram]

the Semaphore approach is it the solution to multiple user is running the same process at the same time and it causes lock cube ?

my scenario is more like one process is running and it reads the data from the cube and writes the data back to the cube. so it is a continues read and write when the process is executed. will that cause TI ‘thrashing’ ?

You are aware that the technote you referred to is specific to versions 9.5.2 + only (and then only when using ParallelInteraction=T)?
The "TI thrashing" being referred to is when multiple TIs are trying to write to the same object or the TI is trying to write to the same object as users. When lock contention is encountered one process will have to rollback and then attempt it's update actions again (in which case the lock contention may be encountered a 2nd, 3rd, ... nth time subsequently before finally getting through, or worst case being held in a deadlock holding pattern). This is what is meant by "TI thrashing".

In your case where it seems you have a single process performing the update and writing back to the cube being used as the data source then this scenario isn't relevant and no this shouldn't in isolation cause "TI thrashing". However in the situation where the same object is being used as the target for updates as well as the data source this can cause some pretty severe performance issues and you may find that it is faster to export the source as a flat file and then do the update actions using the flat file as the data source.

[winsonlee]

thanks lotsaram. you have explained it better compare to what i am able to find in IBM website. Is it a common practise to export to text file and do the update actions using the flat file as the data source ?