dtm lock timeout period sets the maximum amount of time, in seconds, that a distributed transaction branch waits for lock resources to become available.
|
Summary Information |
|
|---|---|
|
Default value |
300 (seconds) |
|
Valid values |
1 – 2147483647 (seconds) |
|
Status |
Dynamic |
|
Display level |
10 |
|
Required role |
System administrator |
|
Configuration group |
DTM Administration |
After this time has passed, SAP ASE considers the transaction to be in a deadlock situation, and rolls back the transaction branch that triggered the deadlock. This ultimately rolls back the entire distributed transaction.
Distributed transactions may potentially deadlock themselves if they propagate a transaction to a remote server, and in turn, the remote server propagates a transaction back to the originating server (described in the figure below). The work of distributed transaction “dxact1” is propagated to SAP ASE 2 via “rpc1.” SAP ASE 2 then propagates the transaction back to the coordinating server via “rpc2.” “rpc2” and “dxact1” share the same gtrid but have different branch qualifiers, so they cannot share the same transaction resources. If “rpc2” is awaiting a lock held by “dxact1,” a deadlock situation exists.
SAP ASE cannot detect interserver deadlocks. Instead, it relies on dtm lock timeout period. In the figure above, after dtm lock timeout period has expired, the transaction created for “rpc2” is aborted. This causes SAP ASE 2 to report a failure in its work, and “dxact1” is ultimately aborted as well.
The value of dtm lock timeout period applies only to distributed transactions. Local transactions may use a lock timeout period with the server-wide lock wait period parameter.