Repository navigation
[tx] Dead-thread cleanup discards transactions without rollback; explicit file locks leak forever #4941
Description
Severity: MEDIUM
Location: DatabaseContext.java:190-195 (cleanupDeadThreads only prunes the CONTEXTS map), utility/LockManager (ownership keyed by requester with no liveness sweep / timeout), TransactionContext.java:519-530 (kill() nulls lockedFiles without unlocking).
A thread acquires an explicit lock (acquireLock().type("X").lock()), then dies from an uncaught error before commit/rollback. cleanupDeadThreads removes its context, dropping the only reference to explicitLockedFiles. The LockManager entries remain owned by the dead requester forever; every later commit touching those files times out with LockTimeoutException until restart.
Fix: in cleanupDeadThreads/removeAllContexts, roll back any active TransactionContext found (which releases locks via reset()); optionally add a dead-owner sweep to LockManager for Thread requesters.
Filed from an internal engine deep-audit (2026-07). Traced to source; verify against current main before fixing and add a regression test.
Activity
chore(deps-dev): update setuptools requirement from >=82.0.1 to >=83.…
review(#4939,#4941,#4956): skip inactive transactions in the dead-thr…
Merge main into fix/4939-4941-4956: compose the two getRequester reworks
review(#5060, round 3): volatile requester extends the release guaran…
Merge pull request #5060 from ArcadeData/fix/4939-4941-4956-dbcontext…
lvca commentedon Jul 7, 2026
Fixed in #5060 (merged). The dead-thread sweep now rolls back the transactions a dead thread abandoned - releasing their file locks - instead of just discarding the last reference to them (which left LockManager files owned by a dead requester forever; every later commit touching them timed out until restart). Exactly-once is guaranteed by a two-level atomic claim (the CONTEXTS entry against concurrent sweepers, the per-database key against closeInternal's removeAllContexts), rollback failures log a WARNING with cause/thread/database instead of being swallowed (a failed rollback is precisely this leak persisting), and a sweep that did real work emits one attributable summary WARNING. Red-first verified: both explicit-lock leak tests failed on old code with LockTimeoutException. Nine review rounds hardened the JMM story end to end.
fix(ArcadeData#4939,ArcadeData#4941,ArcadeData#4956): DatabaseContext…
fix(#4939,#4941,#4956): DatabaseContext lifecycle - dead-thread sweep…
review(#4939,#4941,#4956): skip inactive transactions in the dead-thr…
review(#5060, round 3): volatile requester extends the release guaran…