Occasionally, you may need to force a transaction to either commit or abort. This can be necessary, for example, when a communication line fails between two nodes on the network. Once a transaction has been manually committed or aborted, it is often necessary to also manually force a node to "forget" the transaction (that is, to delete the transaction from the local MS DTC log file).
The following example illustrates a case in which a transaction is manually committed. In this example, the following conditions are assumed:
Because the line of communication between nodes A and B is still intact, B has also committed the transaction. Both nodes, however, must retain the COMMITTED records in their log files until nodes C and D confirm that they have also committed the transaction. To resolve the transaction (and thereby release the database locks on nodes C and D), the system administrator forces node C to commit the transaction.
Because the line of communication between nodes C and D is still intact, the forced commit on node C allows the transaction to commit on node D. Node D can now release its database locks and forget the transaction. Once node D confirms to node C that it has committed and forgotten the transaction, node C can also release its locks and forget the transaction.
The transaction is now committed on all nodes; however, because node C cannot communicate its commit to node B, node B must continue to remember the transaction. Because node B has not forgotten the transaction, node A must also remember it. To complete the transaction, the system administrator forces node B to forget the transaction. Node B's forced forget allows node A to also forget the transaction. The two-phase commit protocol has been manually concluded, and the transaction is complete.
Important Because of the outgoing-incoming communication pattern of the two-phase commit protocol, manual resolves should be done on nodes immediately adjacent to the break in communications. Therefore, in the example above, the forced commit occurs on node C (not D), and the forced forget occurs on node B (not A).
You must manually resolve transactions that are either in the In Doubt or the Only Failed Remain to Notify state.
The In Doubt state indicates that the transaction is on a child MS DTC and that the parent MS DTC is inaccessible. To resolve the in-doubt transaction, follow these steps:
The Only Failed Remain to Notify state indicates that the transaction has committed, but some subordinate MS DTCs have not been notified. Resolving transactions that are in the Only Failed Remain to Notify state is difficult because the system provides no easy method of locating the subordinate MS DTCs that have not been notified of the transaction outcome. You must do this manually by examining each system and looking for in-doubt transactions with a global identifier that matches that of the Only Failed Remain to Notify transaction. Once you have located the subordinate MS DTCs, force the transaction to commit on each one. Once you have manually committed the transaction on all subordinate MS DTCs, return to the MS DTC that shows the transaction in the Only Failed Remain to Notify state, and force that MS DTC to forget the transaction.
Caution Do not manually forget a transaction until all subordinate MS DTCs have been notified of the transaction outcome.
This menu displays:
This menu displays: