Reservation-Commit Protocol¶

Protocol — instantiates Use-Time Precondition Binding

Takes the resource out of contention the moment it is checked — an expiring hold that the commit later consumes — so the precondition cannot drift between check and use.

Most use-time bindings detect drift after it happens; this one prevents it. Reservation-Commit Protocol splits the operation into two named phases — reserve, which writes a first-class hold that pulls the resource out of the available pool the instant you check it, and commit, which later consumes that hold. Because the thing you checked is actively held for you, no one else can invalidate it in the gap: contention is resolved once, at reserve time, on a first-to-reserve basis. Its defining move is that the hold is a soft, time-boxed, queryable record — not a raw lock held for the whole duration and not a version compared after the fact — so it can span a long, human-paced gap (a checkout, an approval) and still guarantee the resource is yours when you commit.

Example¶

A ticketing site puts a hot concert on sale. Ten thousand people want the same front-row seats, and the danger is the classic one: two buyers both see seat 10-C free, both proceed to pay, and one gets a seat that was already sold. Reservation-Commit closes that window. When a buyer selects 10-C, the system reserves it — writes a hold record naming that seat, that buyer, and an expiry ≈8 minutes out — and the seat immediately disappears from everyone else's map. The buyer then enters card details and commits; the commit succeeds because the seat was never in contention after the reserve. If the buyer dawdles past eight minutes or abandons the cart, the hold auto-expires and 10-C returns to the pool for the next person — no manual cleanup, no seat stranded forever.

The payoff is certainty at the human timescale: the buyer is told "this seat is held for you," and that promise is real for the length of the lease, even though checkout takes minutes and thousands of others are racing for the same seats.

How it works¶

Reserve pulls the resource out of the pool. The check and the claim are the same act — reserving is the check, and it succeeds only if the unit is still free, so the loser of a race finds out immediately rather than at commit.
The hold is a first-class record. It names the resource, the owner, and an expiry, and it can be queried, extended, or cancelled — unlike an opaque mutex.
Commit consumes the hold. The final action spends the reservation; because the unit was held, the precondition is guaranteed current without a re-check.
Uncommitted holds self-release. Expiry, not a cleanup job, returns stranded units to circulation, so an abandoned reserve cannot leak capacity indefinitely.

Tuning parameters¶

Hold duration — long enough to finish the real work, short enough not to starve the queue. Too long strands inventory; too short evicts users mid-checkout.
Reservation granularity — reserve the exact unit (this seat) or a fungible bucket (any seat in section B). Exact reduces wasted holds; bucket cuts contention but commits later to specifics.
Overbooking factor — reserve more than capacity, betting some holds never commit. Raises throughput and revenue; risks having to bump a committed customer.
Release policy — auto-expiry only, or expiry plus an explicit user-facing cancel that frees the unit sooner.
Extension rule — whether a hold can be renewed mid-checkout, and how many times before it is force-released.

When it helps, and when it misleads¶

Its strength is eliminating double-allocation outright: overbooked seats, double-spent balances, two trucks dispatched for one pallet. Where a check-then-act flow only hopes the world holds still, a reservation makes it hold still for a bounded window, and hands the user a real guarantee they can act on.

Its failure mode is the mirror image of its strength: holds that never release. A too-long lease, a crashed client that leaves an orphaned reservation, or speculative holds placed with no intent to commit all silently drain capacity — inventory that looks sold but isn't, seats no one can buy. The classic misuse is weaponizing the hold: reserving stock to deny it to rivals, or using reservations as an unbounded waiting queue. The discipline that keeps it honest is to make every hold lease-bound with automatic expiry^[1], size the lease to real completion time, and watch the hold-to-commit conversion rate as the early-warning gauge that holds are being taken but not spent.

How it implements the components¶

Reservation-Commit realizes the hold-and-release side of the archetype — the components that keep a resource pinned across the gap, not the ones that detect or react to drift:

reservation_or_hold_record — its core artifact: the first-class, owned, queryable hold that removes the unit from contention at check time.
validity_window_or_lease — the expiry that time-boxes every hold so an abandoned reserve cannot leak capacity.
compensation_or_rollback_path — release-on-expiry (and explicit cancel, or unwinding a hold whose commit fails) returns the unit to the pool.

It does not detect drift with a state_version_or_freshness_token or enforce an atomic_or_exclusive_use_boundary — that's Compare-and-Swap Version Token and Lock or Hold Until Use — and it does not define the conflict_abort_and_retry_policy for the losers of a race, which is Abort-and-Retry After State Mismatch.

Instantiates: Use-Time Precondition Binding — Reservation-Commit binds the precondition by holding the resource across the check–use gap so it stays current.
Sibling mechanisms: Lock or Hold Until Use · Two-Phase Commit with Freshness Check · Compare-and-Swap Version Token · Abort-and-Retry After State Mismatch · Lease-Bound Capability Token · Final Revalidation Before Commit · Confirmation Dialog with State Refresh · Stale Data Revalidation Gate · Snapshot-Pinned Decision · Revocation Status Check at Use · Timestamp and Freshness Badge

Notes¶

Reservation-Commit is pessimistic — it pays the cost of holding up front so the commit is guaranteed. That is the right trade only when a conflict would be expensive or user-visible (a sold-out seat, a double charge). Under low contention, where conflicts are rare and cheap to redo, the optimistic siblings — Compare-and-Swap Version Token paired with Abort-and-Retry After State Mismatch — avoid the holding cost entirely and usually win.

References¶

[1] A lease is a hold that is valid only for a bounded time and must be renewed to persist; if the holder dies or stalls, the lease simply lapses and the resource is reclaimed. Lease-based expiry is the standard guard against the "orphaned lock/hold" problem, and it is what lets a reservation be safely handed to a slow, failure-prone human client. ↩