Distributed Lock Service  ·  View 18 of 26  ·  5 · Runtime

What a Holder Does When It Cannot Confirm Its Lease

A two-stage response in the client library: stop starting work, then fence at a locally computed deadline.

Editable source SVG draw.io All views
Hold Holding keepalive every 5 s Signal Keepalive fails timeout or lost Decide Confirmed in time? Drain Resume holding new deadline Stop starting work finish in-flight Fence onFence callback send time + TTL − 1 s Reacquire new, higher token yes no deadline later What a Holder Does When It Cannot Confirm Its Lease Application we own Risk / gap Decision point Security / platform synchronous The deadline runs from when the last successful keepalive was sent, on the monotonic clock, never from its reply. v 1.0 · owner Platform Architecture · date 2026-09

Decisions

  • On the first failed keepalive the library stops handing out permission to start new units of work but lets in-flight work finish. A transient blip costs a pause, not an aborted batch.
  • At the local deadline the library calls onFence. The deadline is the send time of the last successful keepalive plus the session TTL minus one second, measured on the monotonic clock.
  • Using send time, not reply time, keeps the local deadline strictly earlier than the leader's expiry for that keepalive. The holder always believes it has lost the lock before the log says it has.

What this does not solve

  • A pause that swallows the deadline itself. The library cannot run while the process is frozen, which is view 15 and the reason the token exists.

Rejected alternatives

  • Abort at the first failure: safe, and throws away work on every 200 ms network blip.
  • Continue until told: unsafe by construction. A partitioned holder is never told.
◀  What Each Lock Class Guarantees When Things Break All views Deployment — One Region, Three Failure Domains  ▶
Solution Architecture v1.0 · Platform Architecture · 2026-09 · 26 views · open source, fully on-premises18-holder-when-unconfirmed