Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312110

Summary:

NoWait locking code continues to wait on ReadLock

Product:

z_Archived

Reporter:

Gordon Yorke <gordon.yorke>

Component:

Eclipselink

Assignee:

Gordon Yorke <gordon.yorke>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

desmond.ng, eclipselink.foundation-inbox, sylvain.roulet, tom.ware

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Potential Patch	none

Description Gordon Yorke

2010-05-07 14:41:37 EDT

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.

Comment 1 Gordon Yorke

2010-05-07 15:40:03 EDT

Created attachment 167555 [details]
Potential Patch

This patch ensures that an acquireNoWait or acquireWait will not wait on a readlock.

Comment 2 Gordon Yorke

2010-05-11 13:31:40 EDT

*** Bug 312462 has been marked as a duplicate of this bug. ***

Comment 3 Gordon Yorke

2010-05-11 13:32:25 EDT

See duplicate bug for symptom details

Comment 4 Gordon Yorke

2010-05-14 15:16:19 EDT

path checked in
Reviewed by James Sutherland

Comment 5 sylvain.roulet

2011-09-20 10:07:25 EDT

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)

Comment 6 Tom Ware

2011-09-20 10:17:52 EDT

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.

Comment 7 Eclipse Webmaster

2022-06-09 10:06:10 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink