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

Bug 312480

Summary:

ReadLocks acquired during distributed merge can result in deadlock

Product:

z_Archived

Reporter:

Gordon Yorke <gordon.yorke>

Component:

Eclipselink

Assignee:

Nobody - feel free to take it <nobody>

Status:

RESOLVED WORKSFORME

QA Contact:

Severity:

normal

Priority:

CC:

eclipselink.foundation-inbox

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
proposed patch	none

Description Gordon Yorke

2010-05-11 14:17:58 EDT

During the distributed merge process (cache co-ordination) if a related object has no changes but is needed for the merge then a readlock will be acquired.  This is very similar to bug 261910 and has the same symptoms except the call stack starts in the distributed merge.

Comment 1 Gordon Yorke

2010-05-11 14:27:38 EDT

Symptoms:

	at java.lang.Object.wait(Native Method)
	- waiting on <0x00002aab5f0172e8> (a org.eclipse.persistence.internal.helper.ConcurrencyManager)
	at java.lang.Object.wait(Object.java:485)
	at org.eclipse.persistence.internal.helper.ConcurrencyManager.acquireReadLock(ConcurrencyManager.java:248)
	- locked <0x00002aab5f0172e8> (a org.eclipse.persistence.internal.helper.ConcurrencyManager)
	at org.eclipse.persistence.internal.helper.ConcurrencyManager.checkReadLock(ConcurrencyManager.java:236)
	at org.eclipse.persistence.internal.identitymaps.CacheKey.checkReadLock(CacheKey.java:180)
	at org.eclipse.persistence.internal.identitymaps.IdentityMapManager.getFromIdentityMap(IdentityMapManager.java:702)
	at org.eclipse.persistence.internal.identitymaps.IdentityMapManager.getFromIdentityMap(IdentityMapManager.java:667)
	at org.eclipse.persistence.internal.sessions.ObjectChangeSet.getTargetVersionOfSourceObject(ObjectChangeSet.java:367)
	at org.eclipse.persistence.internal.sessions.ObjectChangeSet.getTargetVersionOfSourceObject(ObjectChangeSet.java:336)
	at org.eclipse.persistence.internal.queries.ContainerPolicy.mergeCascadeParts(ContainerPolicy.java:1067)
	at org.eclipse.persistence.internal.queries.ContainerPolicy.mergeChanges(ContainerPolicy.java:1132)
	- locked <0x00002aac47407aa0> (a java.util.HashSet)
	at org.eclipse.persistence.mappings.CollectionMapping.mergeChangesIntoObject(CollectionMapping.java:1267)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.mergeChangesIntoObject(ObjectBuilder.java:2636)
	at org.eclipse.persistence.internal.sessions.MergeManager.mergeChangesIntoDistributedCache(MergeManager.java:439)

Comment 2 Gordon Yorke

2010-05-11 16:22:40 EDT

Created attachment 168028 [details]
proposed patch

This patch changes the process from acquiring a readlock to transitioning to deferred locks if the readlock can not be obtained.

Comment 3 Gordon Yorke

2010-05-13 08:31:10 EDT

This is not a bug.  The Distributed merge does not acquire locks.  The reported deadlock appears to be a thread dump taken mid-run in a running system and does not indicate a deadlock.

Comment 4 Eclipse Webmaster

2022-06-09 10:14:52 EDT

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

Comment 5 Eclipse Webmaster

2022-06-09 10:29:04 EDT

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