Lease
A time-limited grant may still be used by a former holder after a process pause.
- ExpiryExpiry: Time limit of the exclusive grant.
- RenewalRenewal: The holder proves continued activity.
- TakeoverTakeover: After expiry, a new instance may take over.
Context
Why this is important
Connect time-limited ownership to a verifiable takeover.
Connect time-limited ownership to a verifiable takeover.
Lease: inspect the decision
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. An invoice worker claims order B-1042 with a 30-second lease and renews it while generating the PDF. A long GC pause prevents renewal; after expiry, the coordinator assigns the job to another instance. When the first worker returns, it may still issue a delayed write. The invoice store accepts only the latest fencing token. The job remains available while a stale holder cannot change state.
This is how you read the picture
- Expiry Expiry
- Renewal Renewal
- Takeover Takeover
| Concept | Meaning | Review question |
|---|---|---|
| Expiry | Time limit of the exclusive grant. | What may happen after the invoice lease expires? |
| Renewal | The holder proves continued activity. | How is the stale worker write safely rejected? |
| Takeover | After expiry, a new instance may take over. | Which clock assumption should the decision document? |
Benefits & limitations
Helps if:
- Connect time-limited ownership to a verifiable takeover.
- Derive lease duration from work and recovery objectives.
Boundaries
- Expiry does not automatically stop a paused process.
- Safety depends on expiry, renewal, and takeover sharing the same timing and state assumptions.
In practice
- Set the lease duration from typical processing time, the longest expected pause, and the recovery objective; document when the coordinator may trigger takeover.
- Simulate a garbage-collection pause longer than the lease and check whether the old worker can still submit a write after it resumes.
- Verify that takeover uses a higher fencing token and that the invoice store rejects delayed writes from the previous lease holder.
Read the detailed explanation
A lease grants time-limited permission to perform exclusive work on a resource. The holder renews it regularly; after expiry, a coordinator may assign the work again.
Expiry enables progress despite lost processes, but pauses, network partitions, and clock skew can let a former holder continue working. For writes, a monotonically increasing fencing token complements the time limit.
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. An invoice worker claims order B-1042 with a 30-second lease and renews it while generating the PDF. A long GC pause prevents renewal; after expiry, the coordinator assigns the job to another instance. When the first worker returns, it may still issue a delayed write. The invoice store accepts only the latest fencing token. The job remains available while a stale holder cannot change state. lease fencing and failure detection help compare this decision with adjacent concerns.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What may happen after the invoice lease expires?
View the solution with justification
The coordinator may reassign the work; the old worker may still be running.
ApplyingTransferred to a new situation
How is the stale worker write safely rejected?
View the solution with justification
The resource validates a monotonically increasing fencing token on every write.
EvaluateWeighing an alternative
Which clock assumption should the decision document?
View the solution with justification
Renewal and expiry rules must account for clock skew and pauses.
Explore further
These building blocks continue the thoughts of this page.