The stale holder problem
A client can hold a lease, pause for a long garbage collection or network stall, and wake up believing it still holds the lock. By then the lease expired and another client acquired it. Now two clients think they hold the lock.
Fencing tokens
A fencing token is a number the lock service returns with each grant. It increases every time the lock changes hands. The client must include its token on every protected write.
- The storage system remembers the highest token it has seen.
- A write with a token lower than the highest seen is rejected.
- So a stale holder, carrying an old smaller token, cannot corrupt data.
Why this works
The token turns mutual exclusion into something the downstream resource can enforce, rather than trusting clients to behave. Even a paused old holder is fenced out because its token is now behind.
Key idea
A fencing token is a monotonic number checked by the resource itself, so a stale lock holder is rejected even if it wrongly believes it still owns the lock.