How Distributed Transactions Work

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

The DTC supports transactions that are distributed across two or more Microsoft Windows 95 or Windows 2000 or later systems. Each system has a local transaction manager. All applications and resource managers communicate with their local transaction managers. The transaction managers cooperatively manage transactions that span systems.

When a request arrives with a new transaction, a superior-subordinate relationship is established between the two systems. Usually the transaction manager on the system making the request becomes superior to the transaction manager on the system receiving the request. The idea behind the superior-subordinate relationship is that the superior system drives all the systems subordinate to it using the two-phase commit protocol. Each system can have many systems subordinate to it but can have at most one superior. These superior and subordinate relationships form a tree of relationships called the transaction's commit tree.

The enlisted resource managers are also members of this commit tree. They usually have a subordinate relationship to their local transaction manager. The superior and subordinate relationships are relevant only for a particular transaction. That is, transaction manager A can be the superior to transaction manager B on a particular transaction while functioning as a subordinate to transaction manager B on a different transaction.

When a distributed transaction commits or aborts, the prepare, commit, and abort messages flow outward on the commit tree. Any node of the tree can unilaterally abort a transaction at any time before it agrees to the prepare request sent in the first phase. After a node has prepared, it remains prepared and in-doubt until the commit coordinator tells it to commit or abort the transaction. The root transaction manager of the commit tree is called the global commit coordinator. This coordinator makes the decision to either commit or abort the transaction and is never in doubt.

If a computer fails and then restarts, the transaction manager at that computer tries to determine the outcome of all in-doubt transactions in which it participated. The local transaction manager reads its log file to determine the outcomes of transactions for which it was the commit coordinator and takes one of the following actions:

If it has a superior transaction manager, the local transaction manager determines whether it was previously notified of the outcome of the transaction by the superior transaction manager.
If the local transaction manager is in-doubt regarding a particular transaction, it queries its superior to learn the transactions outcome.

The transaction manager also responds to queries from subordinate transaction managers regarding in-doubt transactions, similar to the protocol that transaction managers and resource managers follow at restart. The transaction manager determines the outcome of each in-doubt transaction and informs the resource managers of the transaction's outcome.

System or communication failures can leave transactions in-doubt for extended periods of time. While a transaction is in-doubt, the resources modified by the transaction remain locked and unavailable to others. The system administrator can use the Component Services administrative tool to resolve transactions that remain in-doubt.

How Distributed Transactions Work

See Also

Additional resources