Administering Distributed Transactions
Applies To: Windows Server 2008
This guide provides information about administering distributed transactions in Microsoft Windows operating systems. It includes an overview of how distributed transactions work, as well as tasks and procedures that you can perform using Microsoft Distributed Transaction Coordinator (MS DTC) components to manage day-to-day operations for distributed transactions.
The Microsoft Distributed Transaction Coordinator (MS DTC) provides services that are designed to ensure successful and complete transactions, even with system failures, process failures, and communication failures. A distributed transaction can be initiated in one of the following ways:
When a transaction updates data on more than one networked computer
When a transaction involves multiple processes on a single computer
In the case of networked transactions, configuration of the MS DTC is often needed. You can administer the MS DTC using the Component Services administrative tool.
Each computer that participates in a distributed transaction manages its own resources and data and also acts in concert with other computers in the transaction. Above all, a distributed transaction must commit or abort its work entirely on all participating computers. The MS DTC performs transaction coordination for participating components, which might include resource managers and transaction managers on multiple computers.
The MS DTC uses the two-phase commit protocol. In phase one, the transaction manager requests each enlisted component to prepare to commit. In phase two, if all enlistees prepare successfully, the transaction manager broadcasts the commit decision.
In general, transactions involve the following steps:
Applications call the transaction manager to begin a transaction.
When the application has prepared its changes, it asks the transaction manager to commit the transaction. The transaction manager keeps a sequential transaction log so that its commit or abort decisions will be durable:
If all components are prepared, the transaction manager commits the transaction and the log is cleared.
If any component cannot be prepared, the transaction manager broadcasts an abort decision to all the elements that are involved in the transaction.
While a component remains prepared but not committed or aborted, it is "in doubt" about whether the transaction committed or aborted. If a component or transaction manager fails, it reconciles in-doubt transactions when it reconnects.
In this guide