Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

ConcurrencyException "Max number of attempts to lock object" in WriteLockManager #2319

Closed
alex-mavr opened this issue Dec 5, 2024 · 7 comments · Fixed by #2323
Closed

ConcurrencyException "Max number of attempts to lock object" in WriteLockManager #2319

alex-mavr opened this issue Dec 5, 2024 · 7 comments · Fixed by #2323

Comments

@alex-mavr
Copy link

Describe the bug
When using second-level cache on eclipselink version 4.0.3 (and on) we occusionally get the following exception

Exception [EclipseLink-2007] (Eclipse Persistence Services - 4.0.3.v202405220658): org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: Max number of attempts to lock object: User{id=-1, name='user', email='user@mail.com', addresses=0} exceeded.  Failed to clone the object.
	at org.eclipse.persistence.exceptions.ConcurrencyException.maxTriesLockOnCloneExceded(ConcurrencyException.java:62)
	at org.eclipse.persistence.internal.helper.WriteLockManager.acquireLocksForClone(WriteLockManager.java:204)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:1068)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:1026)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor.getAndCloneCacheKeyFromParent(UnitOfWorkIdentityMapAccessor.java:211)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor.getFromIdentityMap(UnitOfWorkIdentityMapAccessor.java:139)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:4135)
	at org.eclipse.persistence.queries.ObjectBuildingQuery.registerIndividualResult(ObjectBuildingQuery.java:466)
	at org.eclipse.persistence.queries.ReadObjectQuery.registerResultInUnitOfWork(ReadObjectQuery.java:898)
	at org.eclipse.persistence.queries.ObjectLevelReadQuery.checkEarlyReturn(ObjectLevelReadQuery.java:949)
	at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:850)
	at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1195)
	at org.eclipse.persistence.queries.ReadObjectQuery.execute(ReadObjectQuery.java:448)
	at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1283)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:3025)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1841)

In version 4.0.2 (and older) we get no such exception.
The issue seems to be related to #2118
120511b#diff-feb6a6b57e86e1e75038ef21b8840c8eb0d713ea82d66205ffea78d02211a4edL170

To Reproduce

  1. Clone project https://github.com/alex-mavr/eclipselink-error-2007
  2. Run EclipseLinkBugTest#testConcurrentException unit test (you may need to increase the value of ITERATIONS constant)

Unit test must fail with the stack trace above

Expected behavior
Should be able to acquire lock to perform query
@cserepj
Copy link

cserepj commented Dec 6, 2024

I am seeing complete deadlocks with 4.0.4 and similar exceptions, downgrading to 4.0.2 was only what helped.

@rfelcman
Copy link
Contributor

rfelcman commented Dec 6, 2024

I'd like ask You which Java/JDK is used?

@cserepj
Copy link

cserepj commented Dec 6, 2024

JDK23 from docker image jetty:12-jdk23

@cserepj
Copy link

cserepj commented Dec 6, 2024

And 4.0.3 seems to also be unaffected.

@alex-mavr
Copy link
Author

I'd like ask You which Java/JDK is used?

I've reproduced it on RHEL 8.9 with OpenJDK build 17.0.9+9-LTS and on Win11 with Oracle JDK build 17.0.12+8-LTS-296

rfelcman added a commit to rfelcman/eclipselink that referenced this issue Dec 10, 2024
@rfelcman
ConcurrencyException "Max number of attempts to lock object" in Write…
fe95877 
…LockManager - bugfix

Fixes eclipse-ee4j#2319 in `WriteLockManager` by `toWaitOn.getInstanceLockCondition().await(MAX_WAIT, TimeUnit.MILLISECONDS);` to wait for lock on object (CacheKey) to be released.
Before this fix there was `toWaitOnLockCondition.await(ConcurrencyUtil.SINGLETON.getAcquireWaitTime(), TimeUnit.MILLISECONDS);` which was `toWaitOnLockCondition.await(0, TimeUnit.MILLISECONDS);` in case of default settings -> Zero time ammount to wait.
Additionally there are some other migrations from `synchronized` to ReentrantLock usage for CacheKey related code.

Signed-off-by: Radek Felcman <radek.felcman@oracle.com>
@rfelcman rfelcman mentioned this issue Dec 10, 2024
Merged
rfelcman added a commit to rfelcman/eclipselink that referenced this issue Dec 16, 2024
@rfelcman
ConcurrencyException "Max number of attempts to lock object" in Write…
3b030af 
…LockManager - bugfix (eclipse-ee4j#2323)

Fixes eclipse-ee4j#2319 in `WriteLockManager` by `toWaitOn.getInstanceLockCondition().await(MAX_WAIT, TimeUnit.MILLISECONDS);` to wait for lock on object (CacheKey) to be released.
Before this fix there was `toWaitOnLockCondition.await(ConcurrencyUtil.SINGLETON.getAcquireWaitTime(), TimeUnit.MILLISECONDS);` which was `toWaitOnLockCondition.await(0, TimeUnit.MILLISECONDS);` in case of default settings -> Zero time ammount to wait.
Additionally there are some other migrations from `synchronized` to ReentrantLock usage for CacheKey related code.

Signed-off-by: Radek Felcman <radek.felcman@oracle.com>
(cherry picked from commit e4245e2)
@rfelcman rfelcman mentioned this issue Dec 16, 2024
Merged
rfelcman added a commit that referenced this issue Dec 18, 2024
@rfelcman
ConcurrencyException "Max number of attempts to lock object" in Write…
98f2c87 
…LockManager - bugfix - backport from master (#2329)

* ConcurrencyException "Max number of attempts to lock object" in WriteLockManager - bugfix (#2323)

Fixes #2319 in `WriteLockManager` by `toWaitOn.getInstanceLockCondition().await(MAX_WAIT, TimeUnit.MILLISECONDS);` to wait for lock on object (CacheKey) to be released.
Before this fix there was `toWaitOnLockCondition.await(ConcurrencyUtil.SINGLETON.getAcquireWaitTime(), TimeUnit.MILLISECONDS);` which was `toWaitOnLockCondition.await(0, TimeUnit.MILLISECONDS);` in case of default settings -> Zero time ammount to wait.
Additionally there are some other migrations from `synchronized` to ReentrantLock usage for CacheKey related code.

Signed-off-by: Radek Felcman <radek.felcman@oracle.com>
(cherry picked from commit e4245e2)
@rfelcman
Copy link
Contributor

First release candidate of EclipseLink 4.0.5 (4.0.5-RC1) is available.
You can download it from usual sources like:
Maven Central
Milestone builds: https://download.eclipse.org/rt/eclipselink/milestones/4.0.5/RC1/
List of changes against 4.0.4 is available at: https://github.com/eclipse-ee4j/eclipselink/releases/tag/4.0.5-RC1

@alex-mavr
Copy link
Author

Indeed, the UTs pass. Thank you for the quick fix

@arjantijms arjantijms mentioned this issue Jan 7, 2025
Closed
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@cserepj @rfelcman @alex-mavr