Community
Participate
Working Groups
The basic issue is that WeakIdentityMap.checkCleanup() Java locks the identity map then proceeds to call acquireIfUnownedNoWait(). The intention of the no-wait is to ensure we do not deadlock because of the Java lock. The problem with this code is that this code will wait on a ReadLock. This means another thread may not be able to access the IdentityMap to release the ReadLock. The simple solution is to ensure acquireIfUnownedNoWait() does not wait on ReadLocks.
Created attachment 167555 [details] Potential Patch This patch ensures that an acquireNoWait or acquireWait will not wait on a readlock.
*** Bug 312462 has been marked as a duplicate of this bug. ***
See duplicate bug for symptom details
path checked in Reviewed by James Sutherland
I recently and frequently had this bug (312462) on a production server with heavy load and a 1.1.1 eclpise link version. We 1th try to apply the correction to this version but it does not change. So we are now using 2.0.3 but still have the same lock. When it happen we have many threads locked on : "http-8480-14" daemon prio=1 tid=0x086e9d50 nid=0x69f5 in Object.wait() [0x1d07e000..0x1d07ef00] at java.lang.Object.wait(Native Method) - waiting on <0x32638b40> (a org.eclipse.persistence.internal.helper.ConcurrencyManager) at java.lang.Object.wait(Object.java:474) at org.eclipse.persistence.internal.helper.ConcurrencyManager.acquire(ConcurrencyManager.java:95) - locked <0x32638b40> (a org.eclipse.persistence.internal.helper.ConcurrencyManager) at org.eclipse.persistence.internal.identitymaps.CacheKey.acquire(CacheKey.java:120) at org.eclipse.persistence.internal.identitymaps.AbstractIdentityMap.acquireLock(AbstractIdentityMap.java:101) or "http-8480-20" daemon prio=1 tid=0x08d40b10 nid=0x6a38 in Object.wait() [0x1c1fe000..0x1c1fee00] at java.lang.Object.wait(Native Method) - waiting on <0x330b0010> (a org.eclipse.persistence.internal.helper.ConcurrencyManager) at java.lang.Object.wait(Object.java:474) at org.eclipse.persistence.internal.helper.WriteLockManager.acquireLocksForClone(WriteLockManager.java:82) - locked <0x330b0010> (a org.eclipse.persistence.internal.helper.ConcurrencyManager) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:894) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:832)
I suggest trying our latest release and, if the issue still exists, filing a new bug. Between 2.0.x and the current version, there have been alot of code changes that could address your issue.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
