Lock manager changes to support detached transactions

Prior to Adaptive Server version 12.0, the lock manager could uniquely identify a transaction’s locks by using the spid value of the transaction’s thread. With the new transaction manager, transactions may be detached from their original threads, and have no associated spid. Moreover, multiple threads with different spid values must be able to share the same transaction locks to perform the work of a distributed transaction.

To facilitate these changes, the Adaptive Server version 12.5 and later lock manager uses a unique lock owner ID, rather than a spid, to identify transaction locks. The lock owner ID is independent from the spid that created the transaction, and it persists even when the transaction is detached from a thread. Lock owner IDs provide a way to support transactional locks when transactions have no associated threads, or when a new thread is attached to the transaction.

The lock owner ID is stored in the new loid column of master.dbo.syslocks. You can determine the loid value of a transaction by examining sp_lock or sp_transactions output.

Examining the spid and loid columns from sp_transactions output provides information about a transaction and its thread of control. A spid value of zero indicates that the transaction is detached from its thread of control. Non-zero spid values indicate that the thread of control is currently attached to the transaction.

If the loid value in sp_transactions output is even, then a local transaction owns the lock. Odd loid values indicate that an external transaction owns the lock.

See “Getting information about distributed transactions” for more information about sp_transactions output.