Two-Phase Commit with Freshness Check¶
Commit protocol — instantiates Use-Time Precondition Binding
Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land.
Two-Phase Commit with Freshness Check binds check to use across several parties that must all act together. In the first phase each participant prepares and votes that it can proceed; in the second phase a final freshness re-check runs at the commit boundary, and only if every precondition still holds does the coordinator tell everyone to commit — otherwise the whole thing aborts and each participant rolls back. Its defining move is a last-moment, all-or-nothing gate: the risky window between "everyone agreed" and "everyone acted" is closed by re-verifying freshness at the commit point itself, so no party lands its share of the change on state that went stale during preparation. Where a lock holds one resource still, this coordinates a set of them and reconciles at the end.
Example¶
At a real-estate closing, the pieces are "prepared" over the preceding days: the buyer's financing is approved, title comes back clear, the seller agrees to sign, funds are staged in escrow. Everyone has agreed — but nothing changes hands yet. At the closing table a final set of checks runs at that moment: title is re-run for last-minute liens, the buyer's funds are confirmed still available, no party has withdrawn. Only when all of those pass at once do the deed and the money swap — the atomic commit. If the final title search turns up a fresh lien, the closing aborts and every prepared step unwinds; nobody is left having half-transferred a house. The days-old agreement is never mistaken for permission to act; the commit is gated on freshness re-verified at the boundary.
How it works¶
- Prepare and vote first. Each participant reserves its part and promises it can commit, without yet committing.
- Re-check freshness at the boundary. Just before the point of no return, every precondition is validated again — the step that separates this from a plain commit that trusts the prepare-time agreement.
- Commit only on unanimity. One stale check or one dissenting vote aborts the whole; there is no partial landing.
- Roll back on abort. Every prepared-but-uncommitted step has an unwind path, so a failed commit leaves nothing half-applied.
Tuning parameters¶
- Freshness-check scope — re-verify everything at commit versus only the volatile preconditions; broader is safer, narrower is faster.
- Prepare-window length — how long parties may sit prepared before the commit; longer windows raise the odds something goes stale, and with it the abort rate.
- Abort versus retry — on a stale check, whether to fail outright or re-prepare and try again; retry salvages progress but can livelock under churn.
- Coordinator trust / timeout — how long participants stay prepared if the coordinator goes silent; too long freezes resources, too short abandons live commits.
- Rollback versus compensation — whether prepared work is truly reversible or must be undone by a compensating action; the latter is needed when a step cannot simply be discarded.
When it helps, and when it misleads¶
Its strength is that it is the mechanism for actions that span multiple resources or parties, where a partial commit on stale state is the real disaster. The freshness gate plus all-or-nothing commit is what keeps a set of changes jointly valid at the exact instant they land — a guarantee no single-resource mechanism can give. It is the classic distributed-transaction shape, two-phase commit, hardened with a use-time re-check.[n1]
Its failure mode is that coordination is expensive and the protocol blocks: participants hold resources prepared while they wait, and the notorious weakness is coordinator failure after prepare — everyone sits locked, unable to safely commit or abort. Long prepare windows raise the abort rate because there is more time to go stale, and heavy churn can drive it into repeated abort-and-retry with little forward progress. The classic misuse is weakening or skipping the freshness re-check to shave latency — which turns it back into a plain commit that trusts a days-old agreement, the exact defect the archetype targets. The discipline is to keep prepare windows short, make the freshness check non-negotiable, bound coordinator waits with timeouts, and ensure every prepared step can genuinely roll back.
How it implements the components¶
use_action_boundary— the commit point is the use-action boundary; the mechanism places its freshness gate exactly there, at the instant of no return.conflict_abort_and_retry_policy— a failed freshness check or a dissenting vote triggers a defined abort (and an optional re-prepare) instead of a partial commit.compensation_or_rollback_path— every prepared-but-uncommitted step has an unwind or compensating path, so an abort leaves nothing half-applied.
It does not stamp a validity_window_or_lease (that's Lease-Bound Capability Token) or freeze a single state_version_or_freshness_token to decide against (that's Snapshot-Pinned Decision); it coordinates many parties and gates their joint commit on a fresh check at the boundary.
Related¶
- Instantiates: Use-Time Precondition Binding — it binds check to use by re-verifying freshness at the commit boundary and refusing any partial landing.
- Consumes: the freshness signals it re-checks — e.g. the versioned view from Snapshot-Pinned Decision — and it typically holds prepared resources via a lock (Lock or Hold Until Use) during the prepare window.
- Sibling mechanisms: Lock or Hold Until Use · Snapshot-Pinned Decision · Reservation-Commit Protocol · Final Revalidation Before Commit · Compare-and-Swap Version Token · Lease-Bound Capability Token
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Two-Phase Commit with Freshness Check operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land.
Independent corroboration: The frozen evidence defines Two-Phase Commit with Freshness Check as 'Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Two-Phase Commit with Freshness Check includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Preparing participants, then committing only after revalidating current preconditions combines distributed two-phase commit with optimistic concurrency validation. Gray and Lamport formalize prepare/commit agreement; Kung and Robinson require validation against overlapping writes before changes become global, directly grounding the freshness check.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land.
- Operations Research — operations_research contributes operations research, optimization, and queueing analysis to this mechanism's defining operation—Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land—without displacing the selected primary historical lineage.
- Organizational & Management Science — organizational_management contributes organizational design, management, and operational governance to this mechanism's defining operation—Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land—without displacing the selected primary historical lineage.
- Systems Thinking & Cybernetics — Feedback, system boundaries, stocks, flows, and regulation supplies a distinct formative lineage for the mechanism's two phase commit with freshness check logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science). Authoritative or primary research supports computer_science as the best historical origin: Preparing participants, then committing only after revalidating current preconditions combines distributed two-phase commit with optimistic concurrency validation. Gray and Lamport formalize prepare/commit agreement; Kung and Robinson require validation against overlapping writes before changes become global, directly grounding the freshness check. The cited Gray and Lamport, Consensus on Transaction Commit; Kung and Robinson, On Optimistic Methods for Concurrency Control directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=specialized records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- Gray and Lamport, Consensus on Transaction Commit
- Kung and Robinson, On Optimistic Methods for Concurrency Control
Notes¶
The freshness check is what earns the name. A two-phase commit without it — plain 2PC — guarantees atomicity but not currency: all parties commit together, yet possibly against state that went stale during the prepare window. The archetype's contribution is precisely the second-phase re-verification that closes that gap.
[n1] Two-phase commit coordinates an atomic commit across participants through a prepare/vote phase and then a commit/abort phase. Its classic limitation is blocking: if the coordinator fails after participants have voted to commit, they can be left holding resources, unable to safely resolve on their own. The use-time freshness re-check adds currency to 2PC's atomicity but inherits this coordination cost. ↩