4.5Distributed transactions and two-phase commit

For an architect designing a system in which the inventory database and the payment database live on separate servers, "how to atomically commit an update spanning multiple sites" is a challenge specific to distributed systems. Unlike a COMMIT on a single database, network latency and the failure of some sites must be accounted for. This section builds the judgment needed to decide how to ensure consistency for a distributed transaction, and how to deal with the weakness that two-phase commit carries.

4.5.1The two phases of two-phase commit (2PC)

• Two-phase commit (2PC) is a protocol that, when a single transaction spans multiple database sites (participants), guarantees that all sites commit or roll back atomically together. A coordinator communicates with each participant and drives the process through two phases.
• In the first phase (prepare phase / commit-request phase), the coordinator asks all participants "can you commit?" Each participant writes its own updates to its log and then replies either "ready (YES)" or "refuse (NO)." In the second phase (commit phase), if YES has been received from every participant, the coordinator sends a COMMIT instruction to all participants to finalize the transaction. If even one participant replies NO, or if a reply times out, the coordinator instead sends a ROLLBACK instruction to all participants to undo it.

4.5.22PC's blocking problem and three-phase commit

• The blocking problem is 2PC's biggest weakness: if, immediately after all participants have replied "ready (YES)" in the first phase, the coordinator itself goes down due to a failure, each participant cannot receive an instruction on whether to commit or roll back, and must keep waiting (blocking) without releasing the locks it holds until the coordinator recovers. During this time, other transactions can be affected in a chain, also waiting for those locks to be released.
• Three-phase commit (3PC) inserts a "pre-commit phase" between 2PC's prepare phase and commit phase, making it easier to avoid blocking even when the coordinator fails, through timeouts and state checks among the participants themselves. However, it increases latency due to the additional round of messages, and in situations involving a network partition (the partition-tolerance tradeoff that the CAP theorem addresses), it cannot completely eliminate blocking either, so many latency-sensitive production systems still widely use 2PC today.

Suppose an architect for an e-commerce system is designing a distributed transaction that, at order confirmation, applies simultaneous updates to two separate servers: an inventory database (Site A) and a payment database (Site B). To commit updates at both sites atomically, the design adopts two-phase commit (2PC)—a coordinator (e.g., an application server) runs a first phase asking both sites "are you ready?"; if both the inventory decrement and the payment confirmation reply ready (YES), the coordinator finalizes with a COMMIT instruction in the second phase, and if either replies not ready (NO), it sends a ROLLBACK instruction to both sites instead. The risk the architect must consider here is the coordinator itself crashing immediately after both sites have replied ready—in that case, neither the inventory database nor the payment database can receive an instruction on whether to ultimately commit or roll back, and each falls into a blocking state, unable to release the locks it holds, which could cause other order processing related to inventory or payment to be delayed in a chain as well. It would be a mistake for the architect to judge that "switching to three-phase commit (3PC) completely resolves the blocking problem, so it should be adopted unconditionally"—3PC eases blocking, via an added pre-commit phase and state checks among the participants, but it comes with the cost of increased latency from the extra round of messages, and it still cannot fully eliminate blocking in situations involving a network partition. So for an e-commerce system where low latency is the paramount requirement, combining 2PC with measures that lower the probability of blocking occurring in the first place—such as a highly available coordinator configuration (redundancy, automatic failover)—can be the more practically sound decision.

4.5.3Section summary

• Two-phase commit (2PC) guarantees atomicity for a distributed transaction via a prepare phase (collecting YES/NO) and a commit phase (COMMIT if all YES; ROLLBACK if any NO or timeout)
• 2PC's biggest weakness is the blocking problem (participants keep waiting while holding locks if the coordinator fails)
• Three-phase commit (3PC) eases blocking but adds latency and does not fully eliminate it—combine it with measures like coordinator high availability depending on requirements