Two tasks are deadlocking on the same database resource
Article ID: 12779
Updated On:
Products
Issue/Introduction
Two tasks are accessing the same database at the same time. It is perfectly possible that they run into a deadlock situation with each other.
In such case, CA IDMS catches this deadlock, abends one of the tasks (with an xx29 error status), and writes messages DC001000, DC001001 and DC001002 into the IDMS log. These messages also identify the database resources which were the subject of the deadlock. Usually, they consist of two DIFFERENT resources.
However, it is also possible that only ONE database resource is involved in the deadlock.
Example :
DC001000 V67 T15 T:000000093 TSK1 P:DCEMP2 C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01
DC001001 V67 T15 Txn/RU ID RU NAME SUBSC User ID FE - ID1 FE - ID2 FE - ID3 FE Tskcd
DC001001 V67 T15 000034139 DCEMP2 EMPSS01 USRA03
DC001000 V67 T15 T:000000095 TSK2 P:DCEMP2 C:DEAD WAITING ON R:LTXNLOCK 00000008 0124FF01
DC001001 V67 T15 Txn/RU ID RU NAME SUBSC User ID FE - ID1 FE - ID2 FE - ID3 FE Tskcd
DC001001 V67 T15 000034140 DCEMP2 EMPSS01 USRA01
DC001002 V67 T15 T:000000095 TSK2 P:DCEMP2 C:DEAD DEADLOCKED ON R:LTXNLOCK 00000008 0124FF01
In this case, both tasks TSK1 and TSK2 ran into a deadlock with each other on the same database record with dbkey 75007:1
Is this normal, and if so under what circumstances can this happen ?
Environment
Resolution
This is how the above situation could happen :
Task TSK1 starts a Cobol/DC program DCEMP2, and opens an UPDATE run unit against the EMPDEMO database. It reads an EMPLOYEE with EMP-ID 0001. When this EMPLOYEE record is read, CA IDMS places a shared lock on the record.
Assume that, at that time, task TSK2 also starts a DC program, opens an UPDATE run unit against the same EMPDEMO database and also reads EMPLOYEE with EMP-ID 0001. Again, CA IDMS places a shared lock on the record.
Then, TSK1 wants to update that EMPLOYEE record. To do so, CA IDMS needs to put an exclusive lock on the record. However, the shared lock set by TSK2 prevents us from placing the exclusive lock, and as such, TSK1 goes into a wait.
After that, TSK2, in turn, also wants to update the EMPLOYEE record. Here too, CA IDMS needs to place an exclusive lock on the record, but this cannot be done, due to the shared lock held by TSK1. Result : TSK2 goes into a wait.
The deadlock detector (RHDCDEAD) of CA IDMS detects this situation and will abend one of the tasks. The deadlock messages will point to the same database resource as illustrated above.
Additional Information
More information about locking can be found in our Navigational DML Programming Reference, section Run Units, Locks, and Database Transactions.
Feedback
