In a two-phase commit transaction, every participant has replied VOTE-COMMIT and is holding its locks, waiting for the coordinator's final instruction — but the coordinator crashes before sending COMMIT or ABORT to anyone. Why can't the participants just make a decision themselves, and what state does this leave the system in?

## Who knows the outcome The scenario is the single best-known weakness of two-phase commit, usually called the 'blocking problem,' and it follows directly from how the protocol assigns knowledge. **Only the coordinator** ever knows the transaction's true outcome before it is announced: it alone writes the durable commit-or-abort record that fixes the decision, and only after writing it does it start telling participants. A participant that has voted COMMIT has entered an 'uncertainty period' — it has made an irrevocable promise ('I will commit if told to') but has no way to independently determine what it was actually told, because it was never told anything yet. ## Why guessing is unsafe **Why can't the participant just guess?** Because the two plausible guesses are both unsafe. - **Suppose the participant assumes 'no news is bad news' and unilaterally aborts.** If the coordinator had actually already committed the transaction (durably recorded COMMIT and begun notifying participants, one of which received and applied it before the coordinator crashed), this participant's guess creates a partially-committed transaction — exactly the inconsistency 2PC exists to prevent. - **Now suppose it assumes optimistically and commits.** If the true decision was ABORT — because a different participant voted ABORT and the coordinator recorded that — this participant has now applied changes that must never have happened. There is no rule the participant can apply locally that is safe in every case, because the coordinator is the only party who was told all the votes; the deciding information physically does not exist anywhere the participant can reach. ## Can a peer fill the gap? Could the participant ask another participant what it heard? In practice, **cooperative termination protocols** do exactly this: participants exchange state, and if any one already knows the outcome (it received COMMIT/ABORT before the coordinator died, or hasn't voted yet and can safely abort), that knowledge propagates and unblocks the group. But this only works if at least one participant is 'lucky' enough to already know the answer. If every prepared participant is symmetrically in the dark — the worst case, and not rare, since the coordinator crash could happen the instant after collecting the last vote and before sending any notifications — no amount of chatter manufactures the missing information. This is why 2PC is a blocking protocol: there exists a reachable failure scenario (coordinator crash right after vote collection) in which every surviving process must wait indefinitely for the failed process to recover. ## What the outage feels like What the system experiences during this window is concrete. - Every participant holds the locks it acquired during prepare — it cannot release them, because releasing before knowing the outcome could let another transaction read or write data that might still need to be rolled back. - Any other transaction wanting those same rows queues up behind the blocked locks. - A single coordinator outage does not just delay the one in-doubt transaction; it can cascade into a broader outage across every database that participated, because their lock tables fill up with indefinitely-held locks. This is why 2PC deployments invest heavily in making the coordinator highly available — replicated with fast failover, or backed by a quorum-replicated log — since the coordinator being down even briefly has an outsized blast radius. ## The remedies The real remedies are: (1) **get the coordinator back online quickly** — on recovery it reads its own durable decision record and resumes sending the outcome to unacknowledged participants, the normal safe path; (2) **run a cooperative termination protocol** among participants, which sometimes resolves the block without the coordinator; or (3) **have an operator force a heuristic decision** after a timeout, accepting the risk it might be wrong and require manual reconciliation. **Three-phase commit (3PC)** was designed to reduce this blocking window by adding an extra phase, though it only fully succeeds under a crash-stop model and reintroduces blocking under network partitions. In production, teams facing this trade-off frequently avoid distributed 2PC across service boundaries altogether and use Sagas with compensating actions instead, precisely to avoid a single coordinator crash freezing multiple systems at once.