Locking Objects

You should exclusive-lock persistent objects in a consistent order, including any collections which will be updated by automatic inverse maintenance, to avoid deadlocks when multiple processes attempt to update the same object or attempt to create, update, or delete instances of the same class. Obtaining the exclusive locks in a consistent order will ensure other processes queue behind the process that currently holds the exclusive locks, therefore removing the opportunity for a deadlock to occur.

An example of when locking may be required is an application requiring objects to remain unmodified while an operation is carried out; for example, a trial balance in which account objects are share locked before reading the balance, to guarantee that the latest edition of each account is used. The shared locks are held until the trial balance calculation is complete.