Previous Topic: Distributed Transaction Recovery ConsiderationsNext Topic: Incomplete Transactions and Manual Recovery


Completing Distributed Transactions Using DCMT

Completing InDoubt Transactions Using DCMT

Once you have determined whether an InDoubt transaction's changes should be committed or backed out, issue a DCMT VARY DISTRIBUTED TRANSACTION command specifying COMMIT or BACKOUT as appropriate.

Completing a transaction in this way will mark it as heuristically committed or backed out (with an outcome of HC or HR respectively). After the DCMT command is issued, the transaction will hold no locks, but it will remain active until either:

If resynchronization is allowed to complete the transaction, a check will be made to see if its overall outcome is consistent (meaning that the transaction's changes were either all committed or all backed out). If a mixed outcome is detected, this fact will be reported on the log and the transaction will remain active on the coordinator until a DCMT command is issued causing it to be forgotten.

Completing InCommit or InBackout Transactions Using DCMT

A transaction whose state is InCommit or InBackout holds no locks and, therefore, is not preventing access to any part of the database. Consequently, there is no urgency involved in completing such transactions and they should normally be allowed to complete automatically through resynchronization. However, if resynchronization fails due to an uncorrectable error, such as premature formatting of a journal file, the DCMT VARY DISTRIBUTED TRANSACTION command specifying FORGET can be used to force completion of InCommit or InBackout transactions.

Note: Even specifying FORGET will not cause a transaction to complete if it cannot successfully communicate with all resource managers that still require notification.