Repository navigation
Conversation
- In ConcurrencyManager, catch exceptions in case anything happens that could have resulted in releaseAllLocksAquiredByThreadAlreadyPerformed to remained false and leave a lock applied. - Added a null check in the WriteLockManager.appendLock as the deferred lock manager can sometimes be null. - Added finally clauses to always release locks irrespective of something going wrong.
Ensure deferred lock manager along with its active locks are always cleared
…seWriteLocks() When transitionToDeferredLocks() is called during merge, it duplicates cache keys from mergeManager.getAcquiredLocks() into the DeferredLockManager's activeLocks list without removing them from getAcquiredLocks(). This means both lists can reference the same CacheKey instances. The safety-net cleanup added in releaseWriteLocks() called releaseActiveLocksOnThread() after releaseAllAcquiredLocks(), causing ConcurrencyManager.release() to be invoked twice on the same keys — throwing ConcurrencyException when depth was already zero. Fix: strip keys already released by releaseAllAcquiredLocks() from the DLM's activeLocks before calling releaseActiveLocksOnThread(), so only locks exclusively tracked by the DLM (those appended by appendLock's else-branch after isTransitionedToDeferredLocks was set) are released by the DLM cleanup path.
…e-ee4j#2659 Updates all 46 POM files from 4.0.0-M3.payara-p1 to 4.0.0-M3.payara-p1.fix-2659 to align with eclipse-ee4j#2660 and ensure the build is distinguishable from the unpatched Payara base. Also updates the OSGi Bundle-Version in the core module to 4.0.0.M3_payara-p1_fix-2659 for runtime traceability.
…e-ee4j#2659 Updates all 46 POM files from 4.0.0-M3.payara-p1 to 4.0.0-M3.payara-p1.fix-2659 to align with eclipse-ee4j#2660 and ensure the build is distinguishable from the unpatched Payara base. Also updates the OSGi Bundle-Version in the core module to 4.0.0.M3_payara-p1_fix-2659 for runtime traceability.
|
We've recently moved from Payara6 to Glassfish 8.0.3 I saw another ghost lock scenario in which I received the following error log: |
Summary
Fixes #2659 — NPE in
WriteLockManager.appendLockwhenisTransitionedToDeferredLocksistruebut theDeferredLockManagerfor the current thread has already been removed (e.g. torn down by a concurrentreleaseDeferredLock()at depth 1 with nodeferred locks).
Also fixes a related double-release risk in
UnitOfWorkImpl.releaseWriteLocks():transitionToDeferredLocks()copies (not moves) keys frommergeManager.getAcquiredLocks()intoDeferredLockManager.activeLocks, so calling bothreleaseAllAcquiredLocks()andreleaseActiveLocksOnThread()releases the sameCacheKeyobjects twice.Changes
WriteLockManager.appendLock— null-checkDeferredLockManagerbefore callinggetActiveLocks().add(); fall back tomergeManager.getAcquiredLocks()if null.WriteLockManager.transitionToDeferredLocks(catch block) — null-check before callingsetIsThreadComplete(true)andremoveDeferredLockManager().ObjectChangeSet.getTargetVersionOfSourceObject— wrapacquireDeferredLock()/releaseDeferredLock()in try-finally; null-checksession.getParent()before logging.UnitOfWorkImpl.releaseWriteLocks— afterreleaseAllAcquiredLocks(), strip already-released keys fromDeferredLockManager.activeLocksbefore callingreleaseActiveLocksOnThread()to prevent double-release.Test plan
isTransitionedToDeferredLocks=true) — verify no NPE and no thread hang.ConcurrencyManagerTestReported and diagnosed in: #2659