1 Introduction

This document specifies a comprehensive distributed transaction processing protocol that is referred to in this document as OleTx.

The MSDTC Connection Manager: OleTx Transaction Protocol is a concrete manifestation of the Two-Phase Commit protocol for coordinating the work of multiple parties in a distributed system. This document specifies the syntax and semantics of the protocol but does not attempt to provide a primer on transaction processing in general.

The Two-Phase Commit protocol ensures that work associated with a transaction is atomic across multiple participating resources. Each resource is controlled by a resource manager. A resource manager has the responsibility of interacting with a transaction manager to perform the steps necessary to implement the Two-Phase Commit protocol.

In the first phase of the Two-Phase Commit protocol, the transaction manager asks each participating resource manager to "prepare" for transaction commit. Each resource manager then decides if it can allow the transaction commit to continue or if the transaction will be aborted. Each resource manager informs the transaction manager of its decision through either a "prepared" notification or a "rollback" notification. If all participating resource managers respond with "prepared", thus agreeing that the transaction commit can continue, the transaction manager makes the outcome decision permanent and moves on to the second phase of the Two-Phase Commit protocol.

In the second phase of the Two-Phase Commit protocol, the transaction manager informs all the resource managers of the final outcome decision for the transaction. This step is necessary because when a resource manager provides a "prepared" vote in the first phase, it is in an "in-doubt" state, pending the outcome of the transaction. The resource manager has promised to commit its work on the transaction, but because the final outcome of the transaction is unknown, it cannot yet treat the updates as permanent. The transaction manager informs each resource manager that the transaction either committed or aborted during this second phase. In the case of a commit decision, the resource managers are responsible for acknowledging to the transaction manager that they have received the commit notification. This step is required because the transaction manager has the responsibility of retaining the committed outcome of the transaction until all resource managers have acknowledged that they have received the outcome and have confirmed that they will not request them again.

The Two-Phase Commit protocol is also used between two transaction managers when a transaction  is distributed between them. The originating transaction manager is considered the superior, while the receiving transaction manager is considered subordinate. With respect to the Two-Phase Commit protocol, the superior transaction manager asks the subordinate transaction manager to "prepare" in the first phase, and the subordinate transaction manager then performs the Two-Phase Commit protocol with its resource managers and subordinate transaction managers, if any, before responding "prepared" back to the superior transaction manager. In the second phase, the outcome of the transaction  is communicated from the superior to the subordinate, and the subordinate acknowledges its receipt.

This commit coordination ensures that either all of the resource managers end up committing their work on a transaction, or none of them does, thereby guaranteeing atomicity of the data updated by a single transaction.

Section 1.3.1, covering the transaction lifetime, provides a more complete description of the Two-Phase Commit protocol. Section 10.4 of [GRAY] also provides an excellent description.

The MSDTC Connection Manager: OleTx Transaction Protocol uses the transports protocol described in [MS-CMPO], and the multiplexing protocol described in [MS-CMP], as a transport layer. This protocol provides concrete mechanisms for beginning, propagating, and completing atomic transactions. It also provides mechanisms for coordinating agreement on a single atomic outcome for each transaction  and for reliably distributing that outcome to all participants in the transaction.

This protocol is applicable to application scenarios where atomic transaction processing is a requirement. This protocol is usable in network topologies where the transports protocol, together with the multiplexing protocol, are a viable network transport for establishing long-lived session relationships between the participants in an atomic transaction.

Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.