Reducing Deadlocks

An example of a deadlock situation is where you have a process (for example, P1) that locks an object (for example, Ob1), and another process (for example, P2) that locks an object (for example, Ob2). If P1 now attempts to lock Ob2 and P2 attempts to lock Ob1, both processes will be blocked from completing by the other process.

As soon as Jade identifies a deadlock situation, the process that triggered the deadlock will be given a deadlock exception and the operation will be aborted. In the above example deadlock situation, Jade would give the deadlock exception to P2.

As another example of a deadlock situation, if two processes have share locks on the same object and they both try to upgrade the lock to reserve or exclusive, a deadlock will occur. In this case, the second process to attempt the upgrade receives the deadlock exception. If two processes have share locks on the same object and they both try to upgrade the lock to update, a deadlock will not occur. This is because the share lock is released before the update lock is requested, even if in transaction state.

The more deadlocks you have occurring in your system, the greater the impact will be on the performance of the system, let alone the irritation to the users. It is therefore sensible to take practical steps to reduce the number of deadlocks that occur. There are a number of simple steps to take to assist in this; for example:

• Control the order in which classes are locked. For example, always lock the customer first, then lock the customer’s accounts, then lock the customer account's transactions.

  This is probably best enforced by encapsulating the locking activity.

• Within a class, control the order in which objects are locked. For example, when locking multiple customers, always try to lock in one specific order (for example, the customer number order).

  Enforce this by encapsulating the locking activity.

• Avoid using the beginLock and endLock instruction pair, as it potentially locks too many objects and can make identification of deadlock causes very difficult.

If you impose these sorts of disciplines on all processes, instead of getting deadlocks you will simply wait for locked resources to become available. This is preferable for the end‑user and removes the cost of backing out aborted transactions. It is a lot easier in a project to impose these sorts of disciplines if the operations involving locking and updating are centralized in an application.

You can use the Process::setPersistentDeadlockPriority method to control which user will receive the deadlock exception. You could give higher priority to online users, for example, so that background reports receive the deadlocks or give higher priority to the background reports so that they don't hold locks as long.

If all processes involved in a deadlock have the same deadlock priority, the exception is usually given to the process whose action caused the deadlock.

You can set the DoubleDeadlockException parameter to true in the [JadeServer] section of the Jade initialization file to help diagnose deadlocks. With this setting, both processes involved receive the deadlock exception, which enables you to get two stack dumps to diagnose the contention.