If a function called in an attempt to acquire a resource returns with an error because of a deadlock, the UAP must do the following:

(a) Responses to deadlocks encountered during SUP or SPP processing

If a deadlock occurs during SUP or SPP processing, roll back the transaction using a rollback function (dc_trn_unchained_rollback(), dc_trn_chained_rollback(), or tx_rollback()). The SUP or SPP which is rolled back because of a deadlock is not retried. Reissue the request for the service from the client UAP.

(b) Responses to deadlocks encountered during MHP processing

If a deadlock occurs during MHP processing, call the function dc_mcf_rollback() to roll back the transaction. Whether to retry the MHP can be specified in the argument to the function dc_mcf_rollback().

If a deadlock occurs, detailed information about the UAP which caused the deadlock is output to the directory for the node containing the lock service. This information is called deadlock information.

Suppose that a UAP is waiting for the release of a resource. If the waiting interval exceeds the time specified for lck_wait_timeout in the lock service definition, the function called from the UAP returns with an error. Detailed information about the resource which was about to be acquired can be output to the directory of the node containing the lock service. This information is called timeout information.

Whether to output deadlock information and timeout information can be specified for lck_deadlock_info in the lock service definition.

For details on the output formats of deadlock information and timeout information, see B. Output Format of Deadlock Information.

(a) Deletion of deadlock information and timeout information

Deadlock information and timeout information can be deleted by either of the following methods:

• Delete the information using command
  Execute the lckrminf command.
  
• Delete the information which has been created in online mode when starting OpenTP1
  Specify the deletion conditions in the operands lck_deadlock_info_remove and lck_deadlock_info_ remove_level in the lock service definition.
  

If UAPs which are accessing multiple resource managers encounter a deadlock, OpenTP1 performs the following processing:

(a) Deadlock between RMs (DAM, TAM) which are lock-controlled by OpenTP1

The UAP lock wait priorities specified for deadlock_priority in the user service definition are observed when handling this type of deadlock.

(b) Deadlock between RM (DAM, TAM) which is lock-controlled by OpenTP1 and other vendors' RM

The lock waiting interval limit specified for lck_wait_timeout in the lock service definition is used for monitoring. Since RM-specific waiting interval limits are not referenced, do not forget to specify a lock waiting interval limit in the lock service definition.

(c) Deadlock between other vendors' RMs

Neither RM-specific waiting interval limits nor lock waiting interval limits as specified in the lock service definition are referenced. Instead, the transaction interval limit is used for monitoring UAPs. If the value given to trn_expiration_time in the user service definition, user service default definition, or transaction service definition is exceeded, the corresponding UAP process is terminated abnormally.