Possibility of transaction deadlock

The enqueuing and program isolation scheduling mechanisms, which protect resources against double updating, can cause a situation known as transaction deadlock.

As shown in Figure 1, transaction deadlock means that two (or more) tasks cannot proceed because each task is waiting for the release of a resource that is enqueued upon by the other. (The enqueuing, DL/I program isolation scheduling action, or VSAM RLS locking action protects resources until the next synchronization point is reached.)
Figure 1. Transaction deadlock (generalized)
This diagram illustrates how two tasks, shown as task A and task B, are running concurrently and updating recoverable resources. The sequence is as follows: Task A updates resource 1, while at the same time task B updates resource 2. Continuing in the same units of of work, which means that locks are still held, A then attempts to update resource 2, while B attempts to update resource 1. The result is deadlock, with each task waiting on the other to release its lock.
If transaction deadlock occurs, one task abends and the other proceeds.
  • Transaction deadlock detection is controlled by the DTIMOUT transaction attribute. If the task remains suspended (inactive) for the specified interval (and SPURGE(YES) is also specified), CICS® initiates an abnormal termination of the task. The CICS supplied mirror transactions, CSMI, CSM1, CSM2, CSM3 and CSM5 have the default settings of DTIMOUT(NO) and SPURGE(NO).
  • If both deadlocked resources are VSAM RLS resources, deadlock detection is performed by VSAM. If VSAM detects an RLS deadlock condition, it returns a deadlock exception condition to CICS, causing CICS file control to abend the transaction with an AFCW abend code. CICS also writes messages and trace entries that identify the members of the deadlock chain.
    Note: VSAM cannot detect a cross-resource deadlock (for example, a deadlock arising from use of RLS and DB2® resources) where another resource manager is involved. VSAM resolves a cross-resource deadlock when the timeout period expires, as defined by either the DTIMOUT or FTIMEOUT parameters, and the waiting request is timed out. In this situation, VSAM cannot determine whether the timeout is caused by a cross-resource deadlock, or by a timeout caused by another transaction acquiring an RLS lock and not releasing it.
  • If the resources are both DL/I databases, DL/I itself detects the potential deadlock as a result of the tasks issuing their scheduling calls. In this case, DL/I causes CICS to abend the task that has the least update activity (with abend code ADCD).
  • If both deadlocked resources are CICS resources (but not both VSAM resources), or one is CICS and the other DL/I, CICS abends the task whose DTIMOUT period elapses first. It is possible for both tasks to time out simultaneously. If neither task has a DTIMOUT period specified, they both remain suspended indefinitely, unless one of them is canceled by a main terminal command.

The abended task may then be backed out by dynamic transaction backout, as described in Transaction backout. (Under certain conditions, the transaction can be restarted automatically, as described under Abnormal termination of a task. Alternatively, the terminal operator may restart the abended transaction.)

For more information, see Designing to avoid transaction deadlocks.