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 T be 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 to the log and forces the record onto stable storage. It then sends a prepare (T) message to all the sites at which T has executed. On receiving the message, the transaction manager at that site determines whether it is willing to commit its portion of T. If the answer is no, it adds a record to the log, and then it responds by sending an abort (T) message to C,. If the answer is yes, it adds a record to the log and forces all the log records corresponding to T onto stable storage. The transaction manager then replies with a ready (T) message to C,.



• 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.