2.4 Ownership Models: Who Controls What, and When?

With one worker, who owns this job? has an obvious answer. Add many workers, a crash, and a sweep that reclaims abandoned work, and the same question acquires time and contention: ownership can be claimed, can expire, and can be reclaimed, and a holder that went away can return to find its claim gone. An ownership model keeps those relationships and discards the rest — who holds what, on what terms, and for how long.

2.4.1 The Canonical Move: Resource Ownership

Software engineering has a long vocabulary for control over a shared resource: locks and leases11. Cary G. Gray and David R. Cheriton, “Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency,” in “Proceedings of the Twelfth ACM Symposium on Operating Systems Principles,” special issue, Proceedings of the Twelfth ACM Symposium on Operating Systems Principles (New York), 1989, 202–10, https://doi.org/10.1145/74850.74870., resource-allocation relationships, capability and claim relationships, ownership transfer, and the lifecycle of a claim from acquisition through expiry to reclamation. Ownership is the family the earlier chapters most obviously touch. A claim relates a holder to a resource, which is structural; the claim is acquired, held, and released over time, which is behavioral. That overlap is why ownership is the natural place to show one representation carrying more than one class of question (Figure 2.4-1).

Canonical ownership model: a claim relates a holder to a resource, with time An ownership opener. Worker A holds the current claim on Job 42, stamped with owner, generation, and expiry. A struck-through dashed arrow marks Worker B's stale claim, which cannot supersede the current one. Caption: Question, Semantics, Typical analysis. Blue ground marks the ownership family. Ownership model — who controls what, and when? Worker A Job 42 owner · epoch · expiry Worker B owns (current claim) stale claim — cannot supersede Question: Who controls what, and when? Semantics: node = a holder or a resource; edge = a claim, stamped with a generation and a lifetime. Typical analysis: interleaving exploration; invariant checking over claims.
Figure 2.4-1. The ownership move: a claim over time. A claim binds a holder to a resource and carries the generation and lifetime that tell a current claim from a superseded one; a second, stale claimant is exactly what the generation exists to reject. Its analyses explore concurrent interleavings for an invariant violation.

A claim binds a holder to a resource and carries the facts that make contention decidable: which holder, which generation of claim, and when it expires. The generation is the fact a bare "A owns X" edge cannot express — it distinguishes a current claim from a superseded one. The properties a designer wants to state follow from that: at most one valid holder at a time, a stale holder cannot affect the current one, a release or transfer is valid only from the current claim, and abandoned work is eventually reclaimed.

The hard failures do not live in any single transition. They live in the interleavings: the orders in which concurrent claims, expiries, and reclaims can occur. So the characteristic analysis is state-space exploration over those sequences, with an invariant checked at each reachable configuration. This is the behavioral toolkit of the previous chapter pointed at a concurrency question, which is again why ownership reads as an overlap family.

2.4.2 DocAble: In-Flight Ownership

DocAble leases each in-flight job to one worker. A lease carries an owner, a monotonically increasing generation, and a lifetime; when a lease looks abandoned it can be reclaimed and the job re-leased to another worker at the next generation.

MODEL CARD

In-flight lease · Ownership

Start with what the model means. A job is leased exactly when it has an owner; the two are the same fact seen from two sides, so the model represents ownership as the presence of a current claim rather than as a separate flag that could disagree with it. That is a definition, not a property that could fail. It sets up the invariant that can.

The consequential invariant is about time and contention. Suppose worker A holds the claim at generation 7, appears to stall, and is reclaimed; the job is re-leased to worker B at generation 8. If A now wakes and tries to release using its generation-7 claim, that release must not clear B's current generation-8 claim. The generation makes the distinction decidable: a release carrying an old generation names a claim that no longer owns, so it is inapplicable to the current one.

Figure 2.4-2 draws the claim and its lifetime; the generation is the small addition that separates a live claim from a stale one.

In-flight ownership: CLAIMED releases on merge or becomes reclaimable on expiry A claim opens the CLAIMED state, carrying owner, epoch, and expires_at. Two transitions leave it. Merge releases the claim to a RELEASED outcome. Expiry moves it to RECLAIMABLE, a lapsed state from which another actor may claim it again. The model distinguishes a live claim from a stale one and states when the window has lapsed, without representing the storage machinery that implements the lease. IN-FLIGHT OWNERSHIP claim CLAIMED owner · epoch · expires_at merge expiry RELEASED claim ends cleanly RECLAIMABLE lease lapsed / stale another actor may claim Merge releases the claim; expiry makes it reclaimable. A live claim is distinguishable from a stale one — expiry is a state, not an accident.
Figure 2.4-2. In-flight ownership model. A current claim records owner, epoch, and lifetime. Merge releases the claim; expiry makes it reclaimable. The model distinguishes a live claim from a stale one without representing the storage machinery that implements the lease.

As with the recovery ordering, the two layers stay separate. The generation exposes the question — is this release applicable to the current claim? — as one a checker or a release path can decide. Whether the running system holds the line — whether the release path actually compares generations and rejects the stale one — is a matter of enforcement for Part III. That guard is a hard one: the mechanism refuses the stale release rather than merely reporting it, and an exhaustive search over the interleavings serves as its verification. Here the model's job ends at making the invariant precise and checkable.

2.4.3 One Representation, Several Questions

The lease is the Part's clearest case of one representation answering several classes of question. Read it as an ownership model and it says who controls a job. Read the same claims as a behavioral model and they trace a lifecycle — claimed, held, expired, reclaimed. Count the active leases and the same representation becomes a measurement: how much work is genuinely in flight right now. Figure 2.4-3 sets the three readings side by side.

One shared lease state answers ownership, behavioral, and measurement questions A single shared lease state, carrying owner, epoch, and lifetime, sits at the top and fans down to three purpose-views: ownership, who owns it; behavioral, when is it stale; and measurement, how many are active. One represented state, several engineering questions. Model classes distinguish purpose, not storage objects. SHARED LEASE STATE owner · epoch · lifetime OWNERSHIP who owns? BEHAVIOR when stale? MEASUREMENT how many active? One represented state, several engineering questions.
Figure 2.4-3. Model classes overlap. The same lease state supports ownership, behavioral, and measurement questions. The classes distinguish purpose, not storage objects.

That a lease supports ownership, behavioral, and measurement questions at once is not a sign the model is under-specified. It is the point the classes have been making since the opening chapter: they sort questions, not data structures, and one purposeful representation can answer several when they share the same underlying facts. This is the observation the closing chapter builds on when it connects the models through shared identity.

The lease model makes ownership under contention precise and its key invariant checkable. It does not establish that the implementation obeys the invariant, nor decide what should happen when a stale release is attempted — surface a conflict, drop the release, raise an alarm. Modeling names the claim; Alignment determines whether and how the obligation is enforced.

Ownership introduced permission implicitly: a stale claimant may not clear a current lease. The next family makes permission the whole question.

Works Cited

  1. Gray, Cary G., and David R. Cheriton. “Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency.” In “Proceedings of the Twelfth ACM Symposium on Operating Systems Principles.” Special issue, Proceedings of the Twelfth ACM Symposium on Operating Systems Principles (New York), 1989, 202–10. https://doi.org/10.1145/74850.74870.
© James C. Davis, 2026–present