The Runtime Theory

Two-Phase Commit Sequence: Prepare, Vote, Decide, and the Blocking Problem

Walk a 2PC transaction through prepare and vote, coordinator log decisions, commit or abort broadcast, acknowledgments, and the uncertain-state blocking problem.

The Runtime Theory Team08 stages

trace / request.md

COORDINATORSTARTSPREPARE BROADCASTPARTICIPANTS VOTECOORDINATORDECIDESDECISIONBROADCASTPARTICIPANTSAPPLY AND ACKCOORDINATORCOMPLETESTHE BLOCKINGPROBLEM

readyThe coordinator begins the transaction and writes a start record to its own log. Every participant's changes stay tentative until the coordinator decides.

Two-phase commit buys atomicity with coordination. In phase one, the coordinator asks everyone to prepare — to make their votes durable and hold their resources. In phase two, it reads the votes: unanimity buys a COMMIT, anything else buys ABORT. Every step is written to a log and fsynced before the next step starts, because the coordinator's log is the only memory that survives crashes.

The trade-off is the uncertain state. A participant that voted yes and then lost contact with the coordinator cannot guess the outcome — guessing wrong would commit on one node and abort on another. So it blocks, holding its locks, until the coordinator answers. That blocking is precisely why 2PC is avoided on hot paths and why modern systems prefer Raft (for replicated state) or sagas (for business workflows): the former never blocks, the latter never holds locks across nodes. The sequence matters — vote first, decide second — because the decision must always follow the durable evidence.