Summary

  • A participant votes yes only after recording enough durable state to carry out either commit or abort; the vote removes its unilateral freedom but does not create the global decision.
  • The coordinator's durable decision is a separate protocol fact. If a prepared participant cannot learn it, waiting is safer than converting uncertainty into a contradictory result.
  • Transactional commit governs enlisted resource managers. It does not prove that an email, a human task, a cash dispenser or any other unmanaged external effect completed exactly once.

Imagine a participant restarting after a failure. Its local work succeeded. Its log contains a forced prepare record. It remembers sending an affirmative vote. Yet it has never received the verdict. The tempting status label is “almost committed.” The accurate label is more demanding: prepared and in doubt.

That distinction is one of the most useful ideas in Jim Gray's accounts of transaction processing. It separates readiness from authority. The participant has made its local contribution recoverable and has promised not to improvise. Only a later, durable outcome can tell it which recovery path to follow.

The receipt comes before the verdict

Gray's 1978 Notes on Data Base Operating Systems describes the coordinator asking each participant to reach a state from which it can either redo or undo its portion of the transaction. A participant must place the required log information in safe storage before it replies AGREE. In modern shorthand, it force-writes a prepare or ready record and votes yes.

The record is not a congratulatory receipt. It is evidence of a changed obligation. Before the affirmative vote, the participant may still refuse and abort. After the vote, it must be able to honour either legitimate verdict. It may keep locks, versions or other resources because abandoning them could make the promised commit impossible. Its freedom has narrowed precisely because its promise has become durable.

C. Mohan, Bruce Lindsay and Ron Obermarck make the boundary explicit in their account of transaction management in IBM's R* system. A subordinate force-writes its prepare record, sends YES, enters the prepared state and may no longer commit or abort unilaterally. The protocol has converted private success into a conditional obligation, not into a public outcome.

A unanimous vote is still not the commit record

The coordinator has a different responsibility. It collects votes and, if all required participants agree, force-writes the global commit decision before announcing it. R* calls this durable coordinator record the commit point. If a negative vote arrives, or the decision conditions are not met, the coordinator chooses abort under the protocol's rules.

This order prevents a dangerous shortcut. Suppose one participant interpreted its own YES as commit while another participant failed before voting. The first could expose effects that the second must roll back. Atomicity would have become a set of incompatible local opinions. The extra phase exists so that one durable verdict can govern every enlisted participant.

Even a participant that somehow knows that all others were ready does not automatically acquire the coordinator's authority. Knowledge about votes and authority to establish the outcome are different. The decision record, and an authorised way to discover it, is what closes the uncertainty.

Recovery reconstructs protocol state, not business optimism

Gray's recovery rule is deliberately mechanical. If the participant does not find a forced agreement record, it can abort because no durable promise escaped. If it does find that record, it asks the coordinator for the verdict and performs the corresponding redo or undo. The log answers “what have I promised?” It does not answer “what do I hope happened?”

This is why a useful operating console must keep prepared distinct from committed. Collapsing both into “successful” hides the most consequential uncertainty. A prepared participant may be healthy, its local data may be intact, and every application check may have passed, while the global outcome remains unknown.

The operational evidence should therefore include the coordinator or recovery authority, the durable participant record, the transaction identifier, resources still retained and the age of the in-doubt state. Those are the facts that let an operator recover knowledge. Re-running the business operation or inspecting only the final-looking rows can create a second action without resolving the first.

Blocking is the price of not inventing a decision

If the coordinator disappears after the participant votes yes, the participant may be unable to learn whether a commit record exists. Classic two-phase commit can then block. Gray and Leslie Lamport later made that limitation the starting point for their comparison of 2PC and Paxos Commit: a single coordinator is enough for normal progress, but its failure can stop the protocol.

Blocking is painful because prepared participants may retain locks, storage and capacity. Yet the pause communicates something honest: the participant lacks both sufficient knowledge and unilateral authority. Calling the state committed would favour availability by risking a split outcome; calling it aborted could contradict a decision already made durable elsewhere.

The R* paper discusses heuristic operator decisions for exceptional cases. It also explains the danger. Forcing commit or abort without reliable knowledge can disagree with the true global decision and leave participants inconsistent. A heuristic outcome is therefore a declared breach of the ordinary guarantee, followed by reconciliation work. It is not a clever way to make 2PC non-blocking.

The transaction stops where participation stops

The word “commit” also invites a second overclaim: that every consequence surrounding the transaction is finished. Gray's 1981 paper draws a more exact boundary by distinguishing protected actions from “real actions.” A database can undo protected state. It cannot use a log record to retract cash already dispensed, pull back an email already delivered, reverse a human decision or make an unmanaged machine repeat an action exactly once.

Those effects need their own design. A system may delay the action until after commit, give the action an idempotency key, record a durable request for later delivery, or define a compensating operation. Each option changes the failure semantics. None is conferred automatically by a database commit record.

That boundary matters whenever software joins a transaction to a payment network, message broker, device, ticketing system or human queue. The database may truthfully say “committed” while the external effect is pending, duplicated or failed. Conversely, the external effect may have occurred while the database later aborts. The correct status model names both facts rather than borrowing certainty from one side.

A history with several authors, not a lone-inventor tale

Gray's writing is a powerful route into this distinction, but the history does not support presenting him as the sole inventor of two-phase commit. His own 1978 notes credit earlier recovery work and name Ron Obermarck, Earl Jenner and Steve Weick; they also say that Butler Lampson and Howard Sturgis independently discovered two-phase commit. Mohan, Lindsay and Obermarck authored the R* treatment and its optimizations. Andreas Reuter co-authored the later textbook synthesis, and Leslie Lamport co-authored the Paxos Commit work.

Preserving those boundaries makes the technical lesson sharper. Ideas about logging, atomic commitment, recovery and consensus were refined through several systems and collaborations. Gray's enduring contribution here is not a myth of solitary invention, but an unusually durable way of reasoning about what a system knows, what it has promised and what remains outside its control.

Sources