Fencing Tokens Reject Stale Lease Holders

Tue, 15 Sep 2026 00:00:00 +0700

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.

Fencing Tokens Make Expired Leases Observable

Sun, 13 Sep 2026 00:00:00 +0700

A process can hold a distributed lease, pause long enough for that lease to expire, then resume with local state that still says it owns the resource. Another process may already have acquired a newer lease during the pause. At that point, mutual exclusion in the lock service is not enough: two processes can each act as if they have authority, even though only one lease is current.

This is a boundary problem between coordination and the resource being protected. A lease service can decide which holder is current according to its own state. It cannot retroactively erase instructions already held by an old process, nor can it stop that process from sending a request after a long pause.

Coordination on Nalar

Fencing Tokens Reject Stale Lease Holders

Fencing Tokens Make Expired Leases Observable