The Fencing Token
A lease can fail silently. A client acquires the lock, then pauses for a long garbage collection or gets partitioned. The lease expires, the lock service grants it to a second client, and then the first client wakes up and writes, still believing it holds the lock. Two writers corrupt the resource.
A fencing token closes this gap. Every time the lock service grants the lock it also returns a number that only ever increases. The first client might get token thirty three, and after the lease moves the second client gets token thirty four. Both numbers travel with every write.
The protected resource, such as a storage service, remembers the highest token it has seen. When a write arrives carrying token thirty three after it has already accepted token thirty four, it rejects the stale write. The slow first client is fenced off even though it still thinks it owns the lock.
- Monotonic The lock service must hand out strictly increasing tokens.
- Enforced at the resource The storage layer, not the client, checks tokens.
- Defeats stale holders A paused or partitioned client cannot win against a newer token.
This requires cooperation from the resource. A blind file system that accepts any write cannot be fenced, which is why fencing is built into systems that care about correctness.
Key idea
A fencing token is a monotonic number checked by the resource so that a stale lock holder, however delayed, cannot overwrite work done under a newer token.