Example: Transaction Resolution After System Failure

Article
10/19/2016

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Ordinarily, when systems involved in transactions are restarted and connections restored after a system or connection failure, the DTC automatically resolves the transactions. However, the DTC cannot resolve transactions if the systems are down or connections are not reestablished. In those cases, you can use the Component Services administrative tool on your system to manually resolve transactions that are in the In Doubt, Cannot Notify Abort, or Cannot Notify Commit state.

The following example illustrates a situation in which a communication line fails between two computers on the network. When a transaction has been manually committed or aborted, it is often necessary to manually force a computer to forget the transaction, which deletes the transaction from the local DTC log file.

In this example, the following conditions are assumed:

The DTC on computer A is the commit coordinator.
The lines of communication along which the two-phase commit protocol is conducted proceed sequentially from computer A to computer D.
The first phase of the two-phase commit protocol has concluded, and the commit coordinator has decided to commit the transaction and has written a COMMITTED record to the DTC log file on computer A.
Communication has failed between computers B and C during the second phase of the two-phase commit protocol. Computers C and D remain in doubt regarding the transaction's outcome.
It is difficult or impossible to restore communication between systems B and C.

The transaction is left in an unresolved state, as shown in the following illustration.

Because the line of communication between computers A and B is still intact, both systems have committed the transaction. Computer A has forgotten the transaction because it was permitted to forget the transaction after B acknowledged receipt of the commit notification. Computer B has committed the transaction but must remember the transaction outcome until C knows the outcome. Computer C is in doubt about the transaction's outcome. Computer D is prepared.

To resolve the transaction (and thereby release the database locks on computers C and D), the system administrator forces computer C to commit the transaction. Because the line of communication between computers C and D is still intact, the forced commit on computer C allows the transaction to commit on both computers C and D. Computer D can now release its database locks and forget the transaction. When computer D confirms to computer C that it has committed and forgotten the transaction, computer C can also forget the transaction.

The transaction is now committed on all computers. However, computer B does not know that computer C has committed the transaction because the connection between the two systems remains down. Computer B continues to remember the transaction. To complete the transaction, the system administrator forces computer B to forget the transaction. The two-phase commit protocol has been manually concluded, and the transaction is complete, as shown in the following illustration.

Because of the outgoing-incoming communication pattern of the two-phase commit protocol, you should manually resolve transactions on computers immediately adjacent to the break in communications. Therefore, in the preceding example, the forced commit occurs on computer C (not D), and the forced forget occurs on computer B (not A). If you first forced B to forget and communication was then restored between B and C, the system might automatically abort the transaction on C before you could force it to commit on C. This would result in an inconsistent transaction outcome and could result in resource manager inconsistency.

Example: Transaction Resolution After System Failure

See Also

Additional resources