What is Atomicity?
We introduced the concept of an atomic transaction, which is a program unit that must be executed atomically. That is, either all the operations associated with it are executed to completion, or none are performed. When we are dealing with a distributed system, ensuring the atomicity of a transaction becomes much more complicated than in a centralized system. This difficulty occurs because several sites may be participating in the execution of a single transaction.
The failure of one of these sites, or the failure of a communication link connecting the sites, may result in erroneous computations. Ensuring that the execution of transactions in the distributed system preserves atomicity is the function of the transaction coordinator.
Each site has its own local transaction coordinator, which is responsible for coordinating the execution of all the transactions initiated at that site. For each such transaction, the coordinator is responsible for the following:
• Starting the execution of the transaction
• Breaking the transaction into a number of subtransactions and distributing these subtransactions to the appropriate sites for execution
• Coordinating the termination of the transaction, which may result in the transactions being committed at all sites or aborted at all sites We assume that each local site maintains a log for recovery purposes.
The Two-Phase Commit Protocol
For atomicity to be ensured, all the sites in which a transaction T has executed must agree on the final outcome of the execution. T must either commit at all sites, or it must abort at all sites. To ensure this property, the transaction coordinator of T must execute a commit protocol. Among the simplest and most widely used commit protocols is the two-phase commit (2PC) protocol, which we discuss next. Let Tbe a transaction initiated at site S,, and let the transaction coordinator at Si be C,. When T completes its execution—that is, when all the sites at which T has executed inform C; that T has completed—then C; starts the 2PC protocol.
• Phase 1. C; adds the record
• Phase 2. When C, has received responses to the prepare (T) message from all the sites, or when a pre-specified interval of time has elapsed since the prepare (T) message was sent out, C, can determine whether the transaction T can be committed or aborted. Transaction T can be committed if <£,- has="" received="" a="" ready="">< commit T> or a record < abort T> is added to the log and is forced onto stable storage. At this point, the fate of the transaction has been sealed. Following this, the coordinator sends either a commit (T) or an abort (T) message to all participating sites. When a site receives that message, it records the message in the log. A site at which T has executed can unconditionally abort T at any time prior to its sending the message ready (T) to the coordinator. The ready (T) message is, in effect, a promise by a site to follow the coordinator's order to commit T or to abort T.