| Re: [eclipselink-users] Threads waiting indefinitely in ConcurrencyManager. |
|
Few more updates, We have disabled the L2 cache in the application. I have observed that there is different object id on which the ConcurrencyManager waits for the same thread in different thread dumps. That means when I am looking at the thread dumps taken at different times,
have the same web request thread stuck at the same place but actually is serving a different request. So does it mean that it is not a problem with the eclipselink however there are too many threads waiting for writing to the database and write operation is
slow? Please throw some light. Thanks, From: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx]
On Behalf Of Shashikant Kale Hello, We have been using eclipselink 1.0 (Old application) for application development using JPA. For few days when we are executing performance tests for the application, we are observing threads waiting on object monitor at ConcurrencyManager.
The thread stack shows "ajp-145.245.142.25-8309-79" daemon prio=6 tid=0x0000000008961800 nid=0x1818 in Object.wait() [0x000000001afbd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000a3e60fe8> (a org.eclipse.persistence.internal.helper.ConcurrencyManager) at java.lang.Object.wait(Object.java:485) at org.eclipse.persistence.internal.helper.ConcurrencyManager.acquire(ConcurrencyManager.java:89) - locked <0x00000000a3e60fe8> (a org.eclipse.persistence.internal.helper.ConcurrencyManager) at org.eclipse.persistence.internal.helper.ConcurrencyManager.acquire(ConcurrencyManager.java:75) at org.eclipse.persistence.internal.sequencing.SequencingManager.acquireLock(SequencingManager.java:279) at org.eclipse.persistence.internal.sequencing.SequencingManager$Preallocation_NoTransaction_State.getNextValue(SequencingManager.java:590) at org.eclipse.persistence.internal.sequencing.SequencingManager.getNextValue(SequencingManager.java:884) at org.eclipse.persistence.internal.sequencing.ClientSessionSequencing.getNextValue(ClientSessionSequencing.java:86) at org.eclipse.persistence.internal.descriptors.ObjectBuilder.assignSequenceNumber(ObjectBuilder.java:258) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.assignSequenceNumber(UnitOfWorkImpl.java:405) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNotRegisteredNewObjectForPersist(UnitOfWorkImpl.java:3879) at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.registerNotRegisteredNewObjectForPersist(RepeatableWriteUnitOfWork.java:369) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:3827) - locked <0x00000000fde013a8> (a org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork) at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:219) at com.arisglobal.framework.services.audittrail.AuditTrailServiceImpl.saveAuditTrail(AuditTrailServiceImpl.java:40) I saw a similar
bug fixed in eclipselink 1.2.1 release. However since we are using quite older version (not feasible to upgrade to the latest version due to application production release date) I was not sure how we can apply the patch to the eclipselink. Would appreciate any help regarding this. Thanks,
Disclaimer: This transmission, including attachments, is confidential, proprietary, and may be privileged. It is intended solely for the intended recipient. If you are not the intended recipient, you have received this transmission in error and you are hereby advised that any review, disclosure, copying, distribution, or use of this transmission, or any of the information included therein, is unauthorized and strictly prohibited. If you have received this transmission in error, please immediately notify the sender by reply and permanently delete all copies of this transmission and its attachments. |