BatchUpdateFinish

Semantics

When multiple processes are running in batch update mode and applying changes to a single cube, the TM1® locking scheme may prevent one of the processes from updating the cube. This is by design; when one process obtains a lock to write changes to a cube, other processes will be prevented from writing to that cube in the interest of maintaining data integrity.

This locking scheme can be illustrated using an example of two processes, Process 1 and Process 2, that update a single cube.

• Both processes start and call the BatchUpdateStart function to initiate batch updates.
• Each process operates on a unique data source.
• Process 1 completes processing data and calls the BatchUpdateFinish function. The process obtains a write lock to the cube and commits changes.
• While Process 1 still holds a write lock to the cube, Process 2 completes processing data and calls the BatchUpdateFinish function. However, because Process 1 retains the lock, Process 2 cannot obtain a lock to the cube. All data changes applied in Process 2 are rolled back and Process 2 is restarted. This ensures data integrity.

Depending on the size of the datasource for Process 2, the data rollback and process re-execution can cause a noticeable decrease in performance. To address this performance issue, consider using the BatchUpdateFinishWait function in place of BatchUpdateFinish.

Syntax

BatchUpdateFinish(SaveChanges);