Fencing Tokens
Summary: A mechanism to prevent a node with an expired lease from corrupting shared resources.
Sources: chapter8
Last updated: 2026-04-17
In distributed systems where a node obtains a lease or a lock to access a shared resource (like storage), there is a risk that the node’s lease will expire while it is still processing a request (e.g., due to a process-pauses).
Mechanism
When a lock server grants a lock or lease, it also returns a fencing token, which is a monotonically increasing number (e.g., a counter incremented every time a lock is granted).
The shared resource (e.g., a storage service) must then check the token on every write request. If a request arrives with a token that is smaller than the most recent token it has already processed, it must reject the request as it belongs to a node with an expired lease (source: chapter8, p. 303).
Requirements
- Monotonicity: The tokens must be guaranteed to always increase.
- Server-side verification: The resource itself must take an active role in checking the token; it is not enough to rely on the client checking its own lease status.
(source: chapter8, p. 303)