Skip to main content



      Home
Home » Eclipse Projects » EclipseLink » Random deadlock/hang during commit in EJB3 application
Random deadlock/hang during commit in EJB3 application [message #491656] Thu, 15 October 2009 08:11 Go to next message
Eclipse UserFriend
I'm not sure this issue is caused by EclipeLink, but I really appreciate insight into what could be causing this behaviour.

We are experiencing random deadlocks in our EJB3 application. Sometimes one MDB, when using several threads, locks randomly in transaction commit.

Log contains the following lines before hanging:

UnitOfWork(12587905)--Thread(Thread[RMICallHandler-43,5,HTTP ThreadGroup])--TX beforeCompletion callback, status=STATUS_ACTIVE
UnitOfWork(12587905)--Thread(Thread[RMICallHandler-43,5,HTTP ThreadGroup])--begin unit of work commit
UnitOfWork(12587905)--Thread(Thread[RMICallHandler-43,5,HTTP ThreadGroup])--TX afterCompletion callback, status=COMMITTED

In a normal situation, there would also exist information about end of UnitOfWork.

First we replaced CMT with BMT, but it didn't help. Next the commit was surrounded with a synchronized() call, and this seems to have fixed the issue.

We have encountered this issue with both EclipseLink and TopLink Essentials, and with Oracle database 10G and 11G. Oracle AS is 10G.
Re: Random deadlock/hang during commit in EJB3 application [message #492231 is a reply to message #491656] Mon, 19 October 2009 10:28 Go to previous message
Eclipse UserFriend
If you could get a thread dump, or find were it is locked, that would be helpful.

Do you have a single MDB using multiple threads, or multiple threads each using a MDB?

If you disable the cache (shared=false) does the issue go away?

Previous Topic:retrieving the assigned primary key
Next Topic:Related records as a non-entity collection
Goto Forum:
  


Current Time: Wed Jul 23 14:14:14 EDT 2025

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

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

Back to the top