lock-delay · shipping · also Lock reacquisition delay

Lock-delay

Lock-delay postpones reacquisition of a lock after its holder or associated session is invalidated.

Related Observatory article: Lock-delay on hesela.com

The delay is a coordination safeguard, not a storage-side rejection of old requests. A 2006 lock-service design applies it after holder failure or loss of contact, while normal release permits immediate reacquisition. Its one-minute cap limits unavailability rather than delayed-I/O lifetime. [1]

In Consul, TTL-based expiry has a lower bound; critical health check or explicit destruction can invalidate the session earlier. Lock-delay begins after invalidation. ACL-authorized clients can still perform ordinary KV writes without owning the lock: the delay restricts reacquisition, not all modifications. External storage needs its own enforcement. [2]

Relations

related
Fencing token, I/O fencing

Citations

  1. Mike Burrows. The Chubby lock service for loosely-coupled distributed systems. OSDI 2006, section 2.4. (accessed 2026-10-23)
  2. HashiCorp Consul: Sessions and distributed locks overview, Session Design and K/V Integration. (accessed 2026-10-23)
  3. HashiCorp Consul: Session HTTP API, Create Session, LockDelay field. (accessed 2026-10-23)

Further reading

  1. Hesela: Storage fencing, delayed writes and takeover timing. (accessed 2026-10-23)
Sources & caveats
  • Historical mechanism from Chubby OSDI 2006 section 2.4; it is not a current service-default claim or a cluster benchmark. [1]
  • Consul overview and API pages read 2026-10-23 disagree on allowing zero LockDelay. No zero-setting recommendation or live-service result is asserted. [2] [3]

JSON: /data/terms/lock-delay.json

Published by Hesela team · Updated

Report a correction · Editorial standards · Reuse guidance

Cite this page
Hesela team. Lock-delay. Hesela. 2026-10-23. https://hesela.dev/terms/lock-delay/