Occasionally, under committed access, a deadlock results when two transactions are locking or waiting for access to the same blocks, and neither transaction can complete under these conditions.
For example, if transaction Tx1 needs to update first data block B1 and then data block B2, it first locks B1 and then attempts to lock B2. Meanwhile, if transaction Tx2 needs to update first data block B2 and then block B1, Tx2 first locks B2 and then attempts to lock B1. Tx1 locked B1 and is waiting for B2, and Tx2 locked B2 and is waiting for B1.
Essbase transactions periodically perform deadlock detection while waiting to acquire a lock. If detected, Essbase issues an error message, and the transaction fails.
If you try to update a block that is locked by another user, Essbase behaves in these ways:
If wait is set to indefinite, the transaction waits to acquire the needed locks.
If wait is set to 0 (immediate), and if the required blocks are not immediately available, Essbase displays an error message, and the transaction fails.
If wait is set to a user-specified number of seconds, and the time has expired, Essbase displays an error message and aborts the transaction.
For information about how to set concurrency options, see Specifying Data Integrity Settings.