Skip to content

fix: #101 guard atomic shutdown hook with locked flag#114

Open
bibonix wants to merge 1 commit into
sttc:masterfrom
bibonix:101-shutdown-hook-guard
Open

fix: #101 guard atomic shutdown hook with locked flag#114
bibonix wants to merge 1 commit into
sttc:masterfrom
bibonix:101-shutdown-hook-guard

Conversation

@bibonix

@bibonix bibonix commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

Fixes the spurious unlock at JVM shutdown described in #101. When the shutdown hook is installed before the acquisition loop reports success, a JVM exit during the wait — or an exception thrown by lock() or sleep() before this.locked.set(true) — used to call this.lock.unlock(this.label) for a lock that was never held; with the default empty label that release could match another holder on the server.

The fix in src/main/java/co/stateful/Atomic.java guards the hook body with an early if (!this.locked.get()) return, so the hook short-circuits whenever the acquisition step did not flip the flag. Successful call() paths still unlock through the existing finally block and remove the hook there, so behaviour for held locks is unchanged.

Ran mvn --batch-mode --errors clean install -Pqulice -DskipITs=true against the change: build succeeded, every unit test under src/test/java/co/stateful passed, and Qulice's quality gate completed without new findings.

Closes #101

Skip the unlock call when the lock was never acquired, so a JVM exit during the acquisition wait or after a thrown lock() or sleep() no longer releases another holder's lock through the empty default label.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Atomic shutdown hook unlocks even when the lock was never acquired

2 participants