Fencing Token

A fencing token identifies an ordered writer generation. A protected resource validates the token atomically with each change. Once it has accepted a newer generation, it rejects writes carrying an older one.

The token is a number that only goes up. Hazelcast’s FencedLock documents the property as the basis of the mechanism — “lock holders are ordered by a monotonic fencing token, which increments each time the lock is assigned to a new owner” — and the resource must enforce that order: the protected resource does not need to know who holds the lock, only that it must refuse anything numbered below what it has already accepted.

A paused client can miss the heartbeats that keep its lease alive while a second client acquires the lock. The first may resume without knowing it lost ownership. Suppose its token was 7 and the lock service has now issued 8. If the protected resource has only seen 7, its highest-seen-token rule can still accept another write with 7. The new owner must first register or apply 8 at that resource; after that atomic step, writes with 7 are rejected. Hazelcast’s example includes the new owner passing its token to the external service before the old client resumes. If ownership transfer must immediately exclude old writes, advancing the resource’s fence must be part of that transfer contract. Lease expiry alone does not stop a process from writing. This is a partial failure: the lock service, worker, and resource can have different information about ownership.

Issuance must come from an authorized ordering mechanism, and validation must be serialized with the protected mutation — the same requirement as optimistic concurrency control, where a commit is accepted only against the version it read. Every relevant write path must enforce the rule. A token copied into a log field without a target check provides no fencing.

Fencing does not prove that the newest worker has the newest source data, nor does it deduplicate repeated requests by that worker. Combine it with input versions, operation identity — idempotency — and atomic publication rules. Note what it replaces: without a token, a resource that simply keeps the write it saw last is applying last writer wins, which cannot tell a resumed old worker from a new one. A single-database generation check can advance ownership and enforce it within the same database. That illustrates a different handoff boundary from issuing a token at a separate lock service and later presenting it to an external resource.

See Building Incremental and Idempotent Pipelines for a transactional example.

References

• Hazelcast Documentation, FencedLock