Zombie processing can leave stuck invisible exclusive locks
Under certain rare conditions, transactions will fail with a
#Read-ExclusiveLock transactionConflict failure, and yet the locked object
is not reported as such by System systemLocks and similar methods.
During processing of dead objects, the stone sets an exclusive lock on
the dead until they are returned to the free oop list, to avoid user
sessions from inadvertently creating new references to them during
overlapping transactions (See system configuration option
STN_DEAD_X_LOCKING_ENABLED as a way to disable this mechanism).
Under certain rare conditions, the system can generate "zombie" objects,
which are flagged as dead, but which still have entries in the object table.
In 6.0 code was added to detect and clean up these zombies, but failed to
clear the exclusive lock on the object, leaving it stuck "on". The problem
is noticed when the offending oop is assigned to a session as a free oop and
the session attempts to commit a transaction using the oop for a newly created
object. The transaction will fail with a #Read-ExclusiveLock failure, and
yet the stuck exclusive lock will seem to be invisible -- code like
System>>systemLocks will fail to report it since the lock is not associated
with any particular session.
Workaround
Shutting down and restarting the stone will clear the stuck locks.
Setting STN_DEAD_X_LOCKING_ENABLED to FALSE will avoid this rare problem,
but note the caution documented in the system configuration file regarding
the risk of DB corruption.
Last updated: 2/8/06