Fencing Token
A monotonically increasing number issued with a lock, checked by the resource, so a holder whose lease expired cannot act on stale authority.
This addresses the flaw that makes naive distributed locking unsafe, and it is worth understanding because the flaw is invisible in testing and catastrophic in production.
The scenario: process A acquires a lock with a lease. A then pauses — garbage collection, a scheduler preemption, a network hiccup. The lease expires and process B acquires the lock legally. A wakes up, still believing it holds the lock, and writes. Two writers, mutual exclusion violated, and no component did anything wrong.
Timeouts cannot fix this, because A has no way to know how long it was paused before it acts.
A fencing token does fix it. The lock service issues a strictly increasing number with each grant. Every write carries the token, and the resource being protected rejects any token lower than the highest it has seen. A wakes with token 33, B holds 34, the storage layer refuses A's write. The correctness now sits at the resource rather than depending on the client's belief.
The consequence to design for: this only works if the protected resource can perform the check. Where it cannot — a filesystem, a legacy API, a third-party service — distributed locking cannot be made safe, and the honest answer is to restructure so that mutual exclusion is not required, usually by making the operation idempotent or by partitioning ownership so only one writer exists by construction.