A distributed lease can expire while its holder is paused. The holder may later resume with local state that still says it owns the lease, even though another client has acquired a newer lease. If the protected resource accepts commands solely because a client once acquired ownership, both clients can act during the same logical ownership interval.
Fencing tokens move part of the ownership check to the resource receiving the mutation. Each successful lease acquisition receives a token greater than every token issued before it. The protected resource records the greatest token it has accepted and rejects operations carrying an older value.
The token does not prevent a stale process from running. It prevents that process from making an accepted mutation after a newer owner has established precedence at the resource boundary.
Lease expiry does not revoke a paused process
A lease is usually bounded by time or by continued renewal. That bound controls the coordination service’s view of ownership. It cannot directly erase state from a client process or cancel code already executing elsewhere.
Consider client A acquiring a lease and receiving token 41. It starts preparing a write, then pauses long enough for the lease to expire. Client B acquires the same lease and receives token 42. B now has valid ownership according to the coordinator.
If A resumes, it may still send the write prepared before its pause. A check performed only before the pause cannot establish that A remains current when the resource processes the request. The gap between authorization and mutation is the relevant race.
This can occur without assuming a particular source of delay. Scheduling pauses, network delay, process suspension, or long-running work can all separate lease acquisition from the eventual resource operation. The mechanism only depends on the possibility that an old holder acts after a newer holder exists.
Monotonic tokens establish an order
A fencing token is an epoch attached to ownership. For a single protected lease, later successful acquisitions receive greater values:
client A acquires lease -> token 41
lease expires
client B acquires lease -> token 42The resource can apply a simple admission rule:
accept request if token >= greatest accepted token
reject request if token < greatest accepted tokenIn many designs, accepting equal tokens permits multiple operations from the same lease epoch. A stricter operation may impose additional sequencing inside that epoch, but that is separate from fencing stale holders.
The ordering property matters more than the numeric representation. An integer counter is convenient when the coordination mechanism can issue it atomically. Any representation used for fencing needs an ordering that the resource can compare consistently for the protected ownership domain.
The resource must participate
A token carried only between clients and the lock service provides no fencing at the mutation boundary. The storage system, device controller, service endpoint, or other protected resource must receive the token and enforce the ordering rule.
Suppose B with token 42 writes first. The resource records 42. A later request from A with token 41 is rejected even if A still has stale local state claiming ownership.
This property also means fencing cannot be added purely as a wrapper around a resource that has no place to persist or compare epochs. An intermediary can enforce tokens only if every relevant mutation is forced through that intermediary and its ordering state has suitable consistency for the operation being protected.
For a database-backed resource, the token can often participate in an atomic conditional mutation. The exact statement depends on the schema and database semantics, but the critical property is that comparison and state change occur as one protected operation rather than as a separate check followed by an unconditional write.
A lease and a fencing token solve different parts
The lease lets the coordination system eventually grant ownership to another client when the current holder stops renewing. Fencing addresses commands from a former holder that remain possible after that transition.
Removing the lease leaves no bounded mechanism for transferring ownership after a holder disappears. Removing fencing leaves the resource exposed to a stale holder whose execution outlives its lease. The two mechanisms are complementary when stale execution can reach the protected resource.
A token also does not turn arbitrary distributed operations into a transaction. If one logical action spans several independent resources, each resource needs a suitable admission mechanism, and partial completion remains possible unless another protocol handles atomicity or compensation.
Token scope must match the ownership scope
A monotonic sequence is meaningful only within the domain whose operations it orders. If separate locks protect separate objects, a token from one lock does not automatically establish precedence for another object.
The resource therefore needs enough context to associate the token with the protected identity. A practical request may carry both a resource key and an epoch. The stored high-water mark is then maintained at the scope required by the concurrency rule.
Using one global sequence can provide a total order, but a total order is not required merely to reject stale holders of independent resources. Per-resource or per-lock epochs can be sufficient when their issuance and comparison preserve monotonicity within each domain.
Counter durability affects the guarantee
A fencing scheme fails if the issuer can later reuse an older token while a resource still remembers a greater one. It can also admit stale work if the resource loses its high-water mark and starts accepting old epochs after recovery.
The required durability depends on the failure model. If tokens and resource state survive different failures, their recovery rules must preserve the ordering relation needed by the admission check. Resetting a counter or accepted-token value without coordinating the other side can invalidate the comparison.
Overflow deserves the same treatment. A fixed-width counter that wraps into previously issued values no longer supplies the required monotonic order unless the protocol defines a safe epoch transition before wraparound.
Fencing places authority at the mutation boundary
Distributed ownership is useful only to the extent that protected operations respect it. A lease records current ownership in a coordinator, but an old holder can retain execution capability after that record changes.
A fencing token gives the resource evidence of ownership order at the moment a mutation arrives. Once the resource has accepted a newer epoch, delayed commands from earlier epochs become rejectable rather than merely suspicious. That shifts stale-owner protection from assumptions about client timing to an explicit comparison where state is actually changed.