Oracle7 Server Distributed Systems Volume I: Distributed Data
The Prepare and Commit Phases
The processing of a distributed update has two distinct phases:
| prepare phase | The global coordinator (initiating node) asks participants to prepare (to promise to commit or rollback the transaction, even if there is a failure). |
| commit phase | If all participants respond to the coordinator that they are prepared, the coordinator asks all nodes to commit the transaction. If any participants cannot prepare, the coordinator asks all nodes to roll back the transaction. |
When a user commits a distributed transaction with a COMMIT statement, both phases are performed automatically. The following sections describe each phase in further detail.
Prepare Phase
The first phase in committing a distributed transaction is the prepare phase in which the commit of the transaction is not actually carried out. Instead, all nodes referenced in a distributed transaction (except one, known as the commit point site, described ![[*]](jump.gif)
) are told to prepare (to commit). By preparing, a node records enough information so that it can subsequently either commit or abort the transaction (in which case, a rollback will be performed), regardless of
intervening failures.
When a node responds to its requestor that it has prepared, the prepared node has made a promise to be able to either commit or roll back the transaction later and not to make a unilateral decision on whether to commit or roll back the transaction.
Note: Queries that start after a node has prepared cannot access the associated locked data until all phases are complete (an insignificant amount of time unless a failure occurs).
When a node is told to prepare, it can respond with one of
three responses:
| prepared | Data on the node has been modified by a statement in the distributed transaction, and the node has successfully prepared. |
| read-only | No data on the node has been, or can be, modified (only queried), so no prepare is necessary. |
| abort | The node cannot successfully prepare. |
Prepare Phase Actions by Nodes
To complete the prepare phase, each node performs the
following actions:
- The node requests its descendants (nodes subsequently referenced) to prepare.
- The node checks to see if the transaction changes data on that node or any of its descendants. If there is no update, the node skips the next steps and replies with a read-only message
(see below).
- The node allocates all resources it needs to commit the transaction if data is updated.
- The node flushes any entries corresponding to changes made by that transaction to its local redo log.
- The node guarantees that locks held for that transaction are able to survive a failure.
- The node responds to the node that referenced it in the distributed transaction with a prepared message or, if its prepare or the prepare of one of its descendents was unsuccessful, with an abort message (see below).
These actions guarantee that the transaction can subsequently commit or roll back on that node. The prepared nodes then wait until a COMMIT or ROLLBACK is sent. Once the node(s) are prepared, the transaction is said to be in-doubt.
Read-only Response
When a node is asked to prepare and the SQL statements affecting the database do not change that node's data, the node responds to the node that referenced it with a read-only message. These nodes do not participate in the second phase (the commit phase). For more information about read-only distributed transactions, see "Read-Only Distributed Transactions"
Unsuccessful Prepare
When a node cannot successfully prepare, it performs the
following actions:
- That node releases any resources currently held by the transaction and rolls back the local portion of the transaction.
- The node responds to the node that referenced it in the distributed transaction with an abort message.
These actions then propagate to the other nodes involved in the distributed transaction to roll back the transaction and guarantee the integrity of the data in the global database.
Again, this enforces the primary rule of a distributed transaction. All nodes involved in the transaction either all commit or all roll back the transaction at the same logical time.
Commit Phase
The second phase in committing a distributed transaction is the commit phase. Before this phase occurs, all nodes referenced in the distributed transaction have guaranteed that they have the necessary resources to commit the transaction. That is, they are all prepared.
Therefore, the commit phase consists of the following steps:
1. The global coordinator send a message to all nodes telling them to commit the transaction.
2. At each node, Oracle7 commits the local portion of the distributed transaction (releasing locks) and records an additional redo entry in the local redo log, indicating that the transaction has committed.
When the commit phase is complete, the data on all nodes of the distributed system are consistent with one another.
A variety of failure cases, caused by network or system failures, are possible during both the prepare phase and the commit phase. For a description of failure situations and how Oracle7 resolves intervening failures during prepare/commit, see "Troubleshooting Distributed Update Problems" .