Summary information |
|
|---|---|
Default value |
300 (seconds) |
Valid values |
1 to 2147483647 (seconds) |
Status |
Dynamic |
Display level |
10 |
Required role |
System Administrator |
dtm lock timeout period sets the maximum amount of time, in seconds, that a distributed transaction branch will wait for lock resources to become available. After this time has passed, Adaptive Server 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. This situation is shown in Figure 4-2. In Figure 4-2, the work of distributed transaction “dxact1” is propagated to Adaptive Server 2 via “rpc1.” Adaptive Server 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”, then a deadlock situation exists.
Figure 4-2: Distributed transaction deadlock
Adaptive Server does not attempt to detect inter-server deadlocks. Instead, it relies on dtm lock timeout period. In Figure 4-2, after dtm lock timeout period has expired, the transaction created for “rpc2” is aborted. This causes Adaptive Server 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.
Adaptive Server does not use dtm lock timeout
period to detect deadlocks on system tables.
