Lease, Lock, or Reservation Token¶
Temporary-binding protocol — instantiates Use-Time Referent Validation
Binds a referent to one actor for a bounded window with an expiry, so within the window the holder may act without re-checking, and on expiry, release, or commit the binding dissolves for others to claim.
Instead of re-validating a referent at every use, Lease, Lock, or Reservation Token reserves it. It grants one actor a temporary, exclusive binding to the referent for a bounded window — a lease, a lock, a hold — during which the holder may act on it without re-checking, and which dissolves on expiry, release, or commit so others may claim it next. Its defining move is to trade validity-by-inspection for validity-by-tenure: rather than asking "is it still valid?" at each moment of use, it makes the referent stay valid for the holder by keeping everyone else off it for a set time. The expiry is the safety valve — a crashed or vanished holder cannot bind the referent forever, because the lease simply lapses and the referent returns to the pool.
Example¶
A delivery platform offers a new order to courier A with a 90-second reservation. While the hold is live, only A can accept it and the dispatcher does not re-poll every nearby courier each second — the order is A's to take for the window. If A accepts within 90 seconds, the reservation converts to a firm assignment (commit); if A ignores it, the lease expires and the order is automatically re-offered to courier B. One holder at a time, bounded by a deadline, with no central re-checking during the window and automatic reclamation the instant it lapses.
How it works¶
- Grant a binding with a deadline. Bind the referent to one holder together with a time-to-live, so the hold is exclusive but self-limiting.
- Act without re-checking inside the window. During the lease the holder may use the referent freely; validity is guaranteed by exclusive tenure, not by inspection at each use.
- Reclaim on expiry, release, or commit. The binding ends when the holder commits, releases early, or the TTL lapses — and lapse is automatic, so a dead holder never blocks the referent indefinitely.
- Renew only while genuinely in use. A heartbeat can extend a lease whose work is ongoing, without making the hold permanent.
Tuning parameters¶
- Lease duration (TTL) — long enough for the holder to finish, short enough to bound how long a dead holder blocks others. The central trade-off.
- Renewal / heartbeat — whether and how the holder extends an active lease. Enables long work but risks a zombie holder renewing forever.
- Exclusivity — exclusive lock versus a shared or reader lease. Shared holds allow safe concurrency; exclusive holds serialize.
- Expiry action — on lapse, reclaim silently, notify the holder, or require confirmation. Sets how surprising a timeout is.
- Clock model — how expiry time is agreed (server clock, logical time). Loose clocks make expiry ambiguous and force a fencing token.
When it helps, and when it misleads¶
Its strength is amortization and liveness: one grant replaces a stream of use-time checks, which is decisive when re-validating each use is costly or the referent must be held across many operations — and the expiry guarantees no referent is bound forever by a crashed holder. It fits reservations, distributed locks, and any "hold this for me while I work" pattern.
Its dangerous case is a lease that expires while the holder still believes it holds it — a clock skew, a long garbage-collection pause, a slow network — after which the holder acts on a referent already re-granted to someone else. The standard guard is a fencing token: a monotonically increasing number issued with each lease that the resource itself checks, rejecting any write from a holder once a newer lease has been handed out.[n1] The classic misuse is trusting the holder's own belief that its lease is still valid instead of having the resource enforce it. The disciplines: keep TTLs as tight as the work allows, and let the resource — not the holder — be the authority on whether the lease still holds.
How it implements the components¶
lease_or_reservation_expiry_rule— it grants the binding with a definite expiry and reclaims the referent on lapse, release, or commit; the expiry rule is the mechanism's core.freshness_window— the lease duration is the window within which the binding is treated as valid without re-checking; choosing it sets how long tenure substitutes for inspection.
It pre-binds rather than inspects: it does not re-resolve the referent at each use (current_validity_predicate, Just-in-Time Existence Check), detect a concurrent version change (identity_and_sameness_test, Compare-and-Swap or Version Guard), or re-check the actor's authority (Capability or Authorization Revalidation).
Related¶
- Instantiates: Use-Time Referent Validation — Lease, Lock, or Reservation Token supplies the temporary exclusive binding that keeps a referent valid for its holder over a window.
- Sibling mechanisms: Compare-and-Swap or Version Guard · Atomic Check-and-Use Operation · Just-in-Time Existence Check · Capability or Authorization Revalidation · Transactional Precondition Guard · Preflight Resource Probe · Revocation or Tombstone Check · Safe Missing-Referent Fallback · Stale Reference Monitor
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Runtime token state binds a referent to one actor and releases it automatically on expiry, release, or commit.
Nearest alternative: Rule, Policy & Commitment — The token conveys a bounded right, but executable reservation-state control is primary.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Concurrent and distributed systems developed expiring locks and reservation tokens to bind a referent to one actor for a bounded interval.
Related originating lineages:
- Operations Research — Reservation and scheduling practice materially shaped scarce-resource allocation under time windows.
Review resolution: Both independent reviews place the primary lineage in computer_science. The queued differences (reported_ambiguity) concern secondary metadata rather than primary provenance. The final retains operations_research only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=true reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
Attribution caveat: The title groups related locks, leases, and reservation tokens across digital and operational settings.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The fencing-token discipline means a robust lease usually leans on a version guard at the resource: the resource honors only the newest token, which is a Compare-and-Swap or Version Guard on the lease generation. Where the atomic and version guards make each individual use safe, a lease makes a span of uses safe by reserving the referent — the right choice when re-checking every use is too costly or the referent must be held across a whole task.
[n1] A fencing token is a real, well-known technique for distributed leases and locks: the lease service hands out a monotonically increasing token with each grant, and the protected resource rejects any operation carrying a token older than the newest it has seen — so a holder whose lease silently expired cannot act after a newer holder has taken over. ↩