18.1.3.3 The Two-Phase Commit Protocol

The Two-Phase Commit Protocol described in [GRAY] defines Phase One and Phase Two. These phases might be informally described as "are you ready", and "go / no go", respectively.

Phase One begins when all the required changes of resource state have been made, and the root application asks the transaction manager to complete it. Phase One ends when the transaction manager has decided the outcome of the transaction; that is, whether all the changes should be made, or whether none of them should be made.

When the root application asks the root transaction manager to complete the transaction, it may make a commit request, asking that all the changes should be made, or an abort request, asking that none of the changes should be made. A commit request causes the root transaction manager to ask each of the subordinate participants involved in the transaction whether they are prepared to commit the changes made. This is called voting on the transaction outcome. Each subordinate participant must vote Read-Only, Prepared, or Aborted. Read-Only and Prepared are positive votes. Aborted is a negative vote. If any subordinate participant votes negatively, the root transaction manager decides that the final outcome of the transaction as a whole is to make no changes, called the Abort Outcome. If every subordinate participant votes positively, then the root transaction manager decides that the final outcome of the transaction as a whole is to make all the changes, called the Commit Outcome. An abort request causes the root transaction manager to notify each subordinate participant to make no changes and to notify each of their respective subordinate participants, if any, to abort the transaction.

A subordinate transaction manager determines its vote by aggregating the votes of its subordinate participants. If a subordinate transaction manager has no subordinate participants or if all of its subordinate participants vote Read-Only, then the subordinate transaction manager votes Read-Only. If at least one subordinate participant votes Prepared and after collecting all votes no subordinate participant votes Aborted, then the subordinate transaction manager votes Prepared. In all other cases, the subordinate transaction manager votes Aborted, in which case it must also notify any of its subordinate participants that had voted Prepared that the transaction has aborted.

Phase Two begins after the root transaction manager decides the outcome of the transaction. In this phase, each subordinate participant that voted Prepared is sent either a request to commit the changes if the outcome was the Commit Outcome, or a request to undo the changes (called a rollback) if the outcome was the Abort Outcome. The root transaction manager also sends the outcome of the transaction to the root application. A subordinate participant that voted Read-Only is not notified of the outcome of the transaction—a resource manager might vote Read-Only if it made no changes as part of the transaction. A subordinate participant that voted Abort is also not notified of outcome of the transaction. Phase Two ends when all transaction outcome notifications have been completed.

This is the Two-Phase Commit Protocol described in [GRAY]. The protocol specified by [MS-DTCO] adds an additional phase, Phase Zero. Phase Zero can be thought of as prefixed to Phase One. It begins when the root application requests completion of the transaction, and ends when all Phase Zero participants have voted that the phase is complete is complete, after which Phase One proceeds as described above. The value of the additional phase is that during Phase Zero, new participants can be enlisted on the transaction. In the protocol described in [GRAY], the set of participants is fixed from the moment that Phase One begins. Phase Zero is a very useful extension in some scenarios. For example, a caching resource manager can be placed between an application and a database resource manager such that all requested changes are held in memory, until the caching resource manager receives a request from the transaction manager to exit Phase Zero. Only then is the database resource manager itself enlisted on the transaction and the changes made to the durable store, yielding potentially significant performance gains.

 
Show: