The stale holder problem
Any lock built on leases or TTLs can be defeated by a long pause. A client acquires the lock, then its process freezes for a garbage collection pause. The lease expires, another client takes the lock, and then the first client wakes up still believing it is the owner. Now two writers target the same resource.
The fix
The lock service issues a fencing token: a number that strictly increases with every grant. The protected resource records the highest token it has seen and rejects any write carrying a smaller token.
- Old holder wakes with token 33.
- New holder already wrote with token 34.
- The storage layer refuses token 33 because 33 is less than 34.
The stale writer is fenced off without any clock or pause assumptions.
Where to enforce
The check must live at the resource, not the client. The storage service, not the application, compares tokens. This is the piece Redlock critics say is mandatory for true correctness.
Key idea
A monotonic fencing token enforced at the resource turns a stale lock holder into a no op, with no reliance on clocks.