Atomic commit and two-phase commit

In classic two-phase commit, a coordinator asks every required participant to prepare. A participant that votes yes must first ensure it can later complete the transaction after a crash, including the necessary recovery state. It has not committed yet. Its vote is a promise to honor a later valid global decision, so it cannot simply discard that promise when a timer expires. A no vote prevents a commit decision. The coordinator must know the complete participant set; silently forgetting one changes the transaction being coordinated.

After receiving all required yes votes, the coordinator durably records commit before telling participants to commit. If a participant votes no, the coordinator can decide abort according to the protocol. Participants record and apply the outcome, release retained resources when safe, and acknowledge as needed for cleanup. Logging details vary with the implementation and optimizations, but the safety argument always identifies which recoverable state authorizes each message. An acknowledgment that was sent before the corresponding persistence boundary cannot serve as durable evidence after a crash.

A participant that has prepared and lost contact with the coordinator may be unable to distinguish a transaction committed elsewhere from one not yet decided. Preserving atomicity can require waiting for authoritative recovery information. This is the blocking behavior of ordinary two-phase commit under relevant failures. A timeout detects missing timely communication, not the truth of the global decision. Retrying messages and querying recovered state are useful; independently inventing an outcome is unsafe when another participant could already have committed.

Replication can improve access to the coordinator’s decision record, but it introduces its own consensus and durability assumptions. A reachable majority of database replicas is not a majority vote among transaction participants. If the transaction requires three shards, two prepared shards do not authorize omitting the third. Also distinguish atomic commit from isolation: all participants can agree to commit transactions whose interleaving still violates an application invariant under weak isolation. Each property needs its own mechanism and tests.

Prepare work may include local validation, log persistence, and waiting for conflicting activity. A fast average shard does not remove the slowest required shard from the path. Record stage durations, the age and count of prepared transactions, and which owner will resolve each one after coordinator restart. Bound how much unrelated application work a transaction performs while retaining locks. A production runbook should identify the decision authority, not instruct an operator to resolve an old prepared transaction solely from its age.

The reliability lab illustrates a deliberately different rule. Press Reset, set replica count to 5 and unavailable replicas to 2, predict whether three available replicas meet the majority, then press Step. For a fresh comparison, Reset, explicitly set replica count to 5 and unavailable replicas to 3, predict, then Step. The diagram counts available replicas only; it has no prepared states or decision log. Explain why its majority cannot replace the requirement for every transaction participant to prepare.