Deadlocks and interactions with automatic restart

DBCTL detects transaction deadlocks, which can occur when two transactions are waiting for the same two resources to become available; that is, both resources are needed by both transactions.

For a description of transaction deadlocks, see Possibility of transaction deadlock.

In Figure 1, transaction A requests and gets a lock on DBCTL resource D. Then transaction B requests and gets a lock on CICS® resource C. Transaction A needs CICS resource C and requests it, but must wait because transaction B has a lock on it. Transaction B needs DBCTL resource D and requests it, but must wait because transaction A has a lock on it. At the end of the sequence, both transactions are waiting for the other to free up a resource, so neither transaction can complete. This situation is transaction deadlock.

If the resources involved in a transaction deadlock are a DBCTL database and a CICS resource, the task that is waiting for the CICS resource is abended after its DTIMOUT period elapses, if you have specified a DTMOUT period. In the example in Figure 1, transaction A is waiting in an enqueue until transaction B frees the lock held for CICS resource C, so it is transaction A that is abended when DTIMOUT expires.

If you do not specify DTIMOUT for the task that is using the CICS resource, both tasks remain suspended indefinitely, unless one of them is canceled by the CICS main terminal operator (as described in Purging a transaction that is using DBCTL).

If the resources involved in a transaction deadlock are both DBCTL databases, DBCTL detects the potential deadlock when the database requests that create the deadlocks are attempted. DBCTL then causes the task with less update activity to be abended. The abend (ADCD) causes all resources to be backed out. If a deadlock is detected when you are using DEDBs, an FD status code is issued instead of an ADCD abend. See Status codes and backout for details.

For DL/I full function databases and DEDBs, if you have specified automatic restart, the task can be restarted at this point. See Automatic restart management. However, this can take place only if the transaction abended in the first (or only) UOW, and there has been no terminal input or output since the initial terminal input was read.