TM1 Forum

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.

winsonlee wrote: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’ ?