Ready is not the same as committed

Cross-Domain EchoesShared pattern · Coordination

A database participant can be ready to make its part of a distributed transaction without having committed it. In a coordinated closing, funds, title checks and signatures can likewise be prepared before the parties authorize the exchange. Both separate local readiness from the decision that lets the whole action proceed. This prevents one participant’s “ready” from being mistaken for everyone’s completed commitment. The database protocol uses durable votes, a recorded decision and recovery rules. The closing illustration adds checks that conditions are still valid at the final boundary. That analogy explains staged coordination; it does not grant a real property transaction the formal atomicity guarantees of a database protocol.

Written comparison

Local readiness

Distributed databases

Durably logged prepare votes

Property transaction coordination

Staged financing, checks and funds

Prepared participants preserve the possibility of joint action without treating it as complete.

A shared decision boundary

Distributed databases

The coordinator’s durable commit/abort decision

Property transaction coordination

Current validity of all required closing conditions

The boundary joins readiness into one decision; the two domains do not share the same enforcement machinery.

Proceed or unwind

Distributed databases

Commit all parts or abort

Property transaction coordination

Authorize the exchange or stop it

The fork makes the non-commit path explicit. Failure handling is part of the design, not an afterthought.

What carries across

Label readiness and commitment as separate states, and identify who can authorize the transition. A collection of locally ready parts is not yet a completed joint action.

Where the comparison stops

A database’s atomicity follows from its stated protocol and failure model. Real legal transfers do not gain that guarantee merely by using a prepare/check metaphor.

• The selected closing illustration rechecks freshness; ordinary two-phase commit does not automatically supply that additional business-rule revalidation.
• Prepared resources can remain tied up during coordinator failure. Readiness is neither successful completion nor a guarantee of nonblocking progress.

Conditions for this comparison

• Participants and required conditions are named, and prepared work has a genuine abort or recovery path.
• The database implementation supplies durable logs and recovery behavior; the coordinated exchange separately establishes what can still be unwound.

Source entries

Shared pattern

Coordination

Prime

Core Idea

Coordination, as Thompson (1967) framed it in his foundational analysis of organizational interdependence, is the active alignment of independently controlled actors or processes so their actions combine into a coherent collective outcome, despite distributed decision-making and incomplete shared information.

Distributed databases

Two-phase commit protocol

Domain-specific abstraction

Core Idea

2PC ensures agreement and atomicity under its failure model but can block when prepared participants cannot learn the coordinator's decision; durable logs, recovery rules and presumed-abort or commit variants shape operation.

Property transaction coordination

Two-Phase Commit with Freshness Check

Mechanism

How it works

- Prepare and vote first. Each participant reserves its part and promises it *can* commit, without yet committing.

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.

When it helps, and when it misleads

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.