Locks need timeout and forced release
Aliases: lock expiry · forced unlock · preemptive release
What it is
Every locking mechanism needs two backstops: timeout release (the lock opens automatically after a set period with no activity) and forced release (someone with the authority can take the lock away from its holder). Without them, one forgotten lock can occupy a piece of shared workspace indefinitely, and the lock's protective function inverts into a single point of failure. Together these mechanisms redefine a lock from "the holder's property" back to "the team's loanable object" — exclusivity is allowed, unlimited exclusivity is not.
Why it happens
Timeout and forced release solve the same problem at two time scales. Timeout handles the no-response case: the holder is gone, and waiting for their confirmation means waiting forever, so the rule must execute in their absence — keyed to an activity signal (still editing) rather than wall-clock duration (held long), so that someone legitimately polishing for an hour is not collateral damage. Forced release handles the responsive-but-uncooperative or urgent cases: the holder is present but refuses, cannot be reached, or the locked region is blocking something more urgent. That needs an escalation exit, but the exit itself must be constrained — who may press it, what happens next, and what becomes of the holder's unsaved changes must all be answered, or forced release degenerates into a channel where the loudest urgency wins. The handover matters too: if the original holder still has uncommitted work, it should survive as a pending version to merge, not evaporate with the lock.
Where it stops holding
There is no universal timeout value: the reasonable hold time for editing a code block and for polishing a passage differ by an order of magnitude, so thresholds should track object type and the historical distribution of hold times, not one global number. The permission design for forced release has its own failure mode: if anyone can grab anyone's lock at will, the lock's exclusivity promise is dead and people retreat into defensive "copy everything local first" behavior. The sound landing spot is restricted forced release — higher privilege or a stated reason required, with automatic notification of the original holder. For very short locks (seconds), timeouts are just noise; those locks should be replaced by lock-free algorithms or automatic merging in the first place.
Applying it
- Define the "inactive" signal per lock type (input, heartbeat, page visibility); base timeouts on activity, not raw duration.
- On timeout, prompt gently first (renew if the holder is still there); with no response, release automatically and notify both sides.
- Open the forced-release entry to restricted roles only, requiring a reason, auto-notifying the original holder, and writing an audit-log entry.
- On release, if the holder has unsaved changes, route them into a pending merge version rather than discarding.
- Verification: injection testing — simulate a holder going offline without releasing, and measure the time from disconnection to the lock becoming usable; over target (say, 15 minutes) is a fail. Then simulate one forced release and check that notification, logging, and preservation of unsaved changes all occur.