Handling deadlocks in the CICS Db2 environment
Deadlocks can occur in a CICS® Db2® system between two or more transactions or between one transaction and another Db2 user. Deadlocks can involve one or two resources.
About this task
This section covers deadlocks only within Db2. If Db2 resources are involved in this type of deadlock, one of the partners in the deadlock times out according to the user-defined IRLM parameters. Other possible deadlocks are where resources outside Db2 are involved.
- Other transactions are often delayed because they access resources held by the partners in the deadlock. This increases the response times for these transactions, which can result in a cascade.
- The resources involved in the deadlock are expected to be used more intensively in the future, because of an increased transaction rate either for the transactions involved in the deadlock or for other transactions.
The IRLM component of the Db2 subsystem performs deadlock detection at user-defined intervals. One of the partners in the deadlock is the victim and receives a -911 or a -913 return code from Db2. The actual return code is determined by the DROLLBACK parameter for the DB2CONN (if a transaction is using a pool thread) or the DB2ENTRY used by the transaction. When DROLLBACK(YES) is specified, the attachment facility initiates a SYNCPOINT ROLLBACK before returning control to the application. Additionally the attachment facility changes the SQL return code returned by Db2 from -913 to -911, and returns -911 to the application. The other partner continues processing after the victim is rolled back.
To solve deadlock situations, you must perform a number of activities. Solving deadlocks means applying changes somewhere in the system to reduce the deadlock likelihood.
- Detect the deadlock.
- Find the resources involved.
- Find the SQL statements involved.
- Find the access path used.
- Determine why the deadlock occurred.
- Make changes to avoid it.