(a) When using the TAM table access facility with table-based lock

A TAM table which has not been locked for update may be updated or accessed more than once during a single transaction. This type of transaction can cause a deadlock. A deadlock will occur in the following cases.

• A table is updated (records are added or deleted) or accessed (with lock specified) more than once during a single transaction.
• The access sequence for updating and accessing a TAM table is as follows:
  Access, then update.
  
• A TAM table is opened outside the transaction range or is opened inside the transaction range with record lock specified (this type of transaction is used in COBOL).
• Another transaction which needs to lock resources accesses the same table at the same time as the transaction described above.

(b) When using the TAM table access facility without table-based lock

A deadlock may occur if you change a TAM table in which records were updated, added, or deleted using the TAM table access facility with table-based lock to a TAM table that uses the TAM table access facility without table-based lock.

When records are updated, added, or deleted using the TAM table access facility with table-based lock, the table is locked for table updating. Therefore, if two or more transactions are set to access the same records to be added or deleted, but in different sequences, no deadlock will occur because the transactions (except the one that is currently accessing records) wait because of table-based lock. However, a deadlock may occur if the records of the TAM table to be accessed are updated, added, or deleted using the TAM table access facility without table-based lock. Therefore, if you change a TAM table in which records were updated, added, or deleted using the TAM table access facility with table-based lock to a TAM table that uses the TAM table access facility without table-based lock, make the sequence in which the UAPs will access the records the same.

The figure below shows an example in which a deadlock occurs after change from a TAM table that uses the TAM table access facility with table-based lock to a TAM table that uses the TAM table access facility without table-based lock.

Figure 4-16 Example in which a deadlock occurs after change from a TAM table that uses the TAM table access facility with table-based lock to a TAM table that uses the TAM table access facility without table-based lock

Assume that UAP1 deletes records 1 and 3 in that order and that UAP2 updates records 3 and 1 in that order. Additionally, assume that the TAM table access facility with table-based lock and the TAM table access facility without table-based lock are performed in the sequence of (1) to (4) in the figure.

The TAM table access facility with table-based lock is performed in the following sequence:

1. To delete record 1, UAP1 locks the table for updating.
2. When UAP2 attempts to lock the table in order to update record 3, it encounters competition with the table lock at step 1. In order to lock the record for reference, it must wait until the table is unlocked.
3. When deleting record 3, UAP1 does not lock any resources.
4. When UAP1's transaction is committed, the table that was locked at step 1 is unlocked. UAP2 can now perform its processing.
   After UAP1's transaction is committed, UAP2 locks the reference table and locks the record to be updated, at step 2. At step 4, UAP2 locks record 1 to be updated.
   

The TAM table access facility without table-based lock is performed in the following sequence:

1. To delete record 1, UAP1 locks the record for updating.
2. To update record 3, UAP2 locks the record for updating.
3. When attempting to delete record 3, UAP1 encounters competition with the lock that was applied at step 2. Before locking the record to be updated, UAP1 must wait until the record is unlocked.
4. When attempting to update record 1, UAP2 encounters competition with the lock that was applied at step 1. Before locking the record to be updated, UAP2 must wait until the record is unlocked. A deadlock thus occurs.

To avoid this deadlock, exchange steps 1 and 3 of UAP1 or exchange steps 2 and 4 of UAP2.

The procedure by which resources are locked is explained below, accompanied by an example in which a resource is updated and added to. For information on locking a TAM table or record, see 4.2.6 Lock for TAM tables.

The figure below shows an example of locking the resource to be updated and added to.

Figure 4-17 Example of update and addition

1. When the function dc_tam_write() is called for updating a resource, the resource is locked as shown in Figure 4-17.
   
   • Table reference lock (PR)
   • Record update lock (EX)
   The record to be updated is in a TAM table which has not been locked for update. The entire table is locked for reference to prevent another transaction from changing the record configuration within the table before the first transaction has ended.
   
2. When the function dc_tam_write() is called for adding to a resource, the resource is locked as shown in Figure 4-17.
   
   • Table update lock (EX)
   Since this function changes the configuration within the table, the entire table is locked for update (EX) to prevent another transaction from referencing the table before the first transaction has ended.
   
3. Processing in steps 1 and 2 changes the lock on the table from a lock for reference (PR) to a lock for update (EX).
   The figure below shows how a deadlock occurs.
   

   Figure 4-18 Occurrence of a deadlock

   

   As shown at (2)-1 in Figure 4-18, another transaction can lock the table for reference (PR) after processing for step 1 has been completed but before processing for step 2 has started. This other transaction then attempts to lock a record updated by the first transaction. It waits for the lock on the record to be released while maintaining the lock for reference (PR) which it specified for the table ((2)-2 in Figure 4-18).
   In processing for step 2, the first transaction cannot lock the table for update (EX) because the other transaction has locked the table for reference (PR). The first transaction waits for the lock to be released.
   
4. In step 3, both transactions wait for each other's resource to be freed. This situation is a deadlock.
   In Figure 4-18, a deadlock occurred because the local transaction continued processing (to the end of step 1) without specifying a lock for update (EX) for the resource (table) it required for addition processing. As a result, it allowed another transaction to lock the table. If the local transaction had specified a lock for update (EX) for the table in advance, the other transaction would not have been able to lock the table.
   Make sure that transactions do not create a situation such as those described in (1) (a) above. For example, a table should not be updated or accessed more than once within a single transaction.
   

If a TAM table must be updated or accessed more than once within a single transaction and a deadlock such as that described above is likely to occur, make sure that the transaction locks the table for update (EX) before it continues processing.

To lock a table for update, update (add or delete) the records first. Alternatively, if your program is in C, open the file so that it is locked within the transaction.