Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Thread hang in ConcurrencyManager.acquire()
Thread hang in ConcurrencyManager.acquire() [message #904002] Mon, 27 August 2012 14:40 Go to next message
Amit B is currently offline Amit BFriend
Messages: 12
Registered: July 2012
Junior Member
We have an application that is using eclipselink, java-odbc driver with a foxpro database. There are other native legacy Foxpro applications which also access the database concurrently. This concurrent access to the tables is being protected against in both the applications using a database field. Most of the time they are accessing different tables except for couple of tables. So, when the Foxpro application tries to access one of these tables it sets a field in a settings table. The Java application will read this field and only make an update to a table once the field is reset by the foxpro application.

The java application also has multiple threads running inside which perform create/read/update operations on the foxpro database. This is where we have been seeing an application hang in the ConcurrencyManager.acquire(). The jpeg image of the stacktrace showing the hang in Netbeans IDE.

index.php/fa/11309/0/

Here's the stack trace from when PM1 Thread is killed (which brought it all back to life). Note* This stack trace does not repeat does not exist until it is manually interrupt the thread which is stuck at ConcurrencyManager.acquire().

PelletOrderThread PelletOrderManager: PM2 attempting lock. - Fri Aug 24 16:09:31 CDT 2012
javax.persistence.RollbackException: Exception [EclipseLink-2004] (Eclipse Persistence Services - 2.4.0.v20120608-r11652): org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to 
commit or rollback a transaction before it was started, or to rollback a transaction twice.
                at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(EntityTransactionImpl.java:66)
                at com.easyautomation.feedpelletpro.db.UserTransaction.commit(UserTransaction.java:43)
                at com.easyautomation.feedpelletpro.db.ServerDataManager.updateNonAutomated(ServerDataManager.java:1768)
                at com.easyautomation.feedpelletpro.db.ServerDataManager.updateHasItemIF(ServerDataManager.java:1641)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.updateBin(PelletOrderManager.java:490)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.processPLCData(PelletOrderManager.java:399)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.checkPLCData(PelletOrderManager.java:1306)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.run(PelletOrderManager.java:92)
                at java.lang.Thread.run(Thread.java:722)
Caused by: Exception [EclipseLink-2004] (Eclipse Persistence Services - 2.4.0.v20120608-r11652): org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to 
commit or rollback a transaction before it was started, or to rollback a transaction twice.
                at org.eclipse.persistence.exceptions.ConcurrencyException.signalAttemptedBeforeWait(ConcurrencyException.java:84)
                at org.eclipse.persistence.internal.helper.ConcurrencyManager.release(ConcurrencyManager.java:409)
                at org.eclipse.persistence.internal.sessions.AbstractSession.rollbackTransaction(AbstractSession.java:3536)
                at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.rollbackTransaction(UnitOfWorkImpl.java:4614)
                at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.rollbackTransaction(RepeatableWriteUnitOfWork.java:522)
                at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.release(UnitOfWorkImpl.java:4421)
                at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInternal(EntityTransactionImpl.java:98)
                at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(EntityTransactionImpl.java:63)
                ... 8 more
Aug 27, 2012 8:25:22 AM com.easyautomation.feedpelletpro.db.UserTransaction rollback
WARNING: Attempted to rollback transaction that wasn't active.
Aug 27, 2012 8:25:22 AM com.easyautomation.feedpelletpro.web.PelletOrderManager run
SEVERE: null
java.lang.IllegalArgumentException: Exception [EclipseLink-2004] (Eclipse Persistence Services - 2.4.0.v20120608-r11652): org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to 
commit or rollback a transaction before it was started, or to rollback a transaction twice.
                at com.easyautomation.feedpelletpro.db.ServerDataManager.updateNonAutomated(ServerDataManager.java:1774)
                at com.easyautomation.feedpelletpro.db.ServerDataManager.updateHasItemIF(ServerDataManager.java:1641)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.updateBin(PelletOrderManager.java:490)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.processPLCData(PelletOrderManager.java:399)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.checkPLCData(PelletOrderManager.java:1306)
                at com.easyautomation.feedpelletpro.web.PelletOrderManager.run(PelletOrderManager.java:92)
                at java.lang.Thread.run(Thread.java:722)
Re: Thread hang in ConcurrencyManager.acquire() [message #904033 is a reply to message #904002] Mon, 27 August 2012 15:35 Go to previous message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1039
Registered: July 2009
Senior Member
Have you seen the faq on diagnosing deadlocks? http://wiki.eclipse.org/EclipseLink/FAQ/JPA#How_to_diagnose_and_resolve_hangs_and_deadlocks.3F

In general, figuring out deadlocks within ConcurrencyManager require looking at the complete thread dump and checking the other threads in EclipseLink code, as one of them is likely to have the lock that the stuck thread is waiting for. To help, you can also call printIdentityMapLocks() on the IdentiyMapAccessor from the Session to dump all of the locks and the thread holding it.
Previous Topic:merging returns old value for referenced entity
Next Topic:Named Query not found
Goto Forum:
  


Current Time: Sun Dec 21 00:29:26 GMT 2014

Powered by FUDForum. Page generated in 0.01492 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software