This issue shall represent and track the problem I reported in the forum at http://www.datanucleus.org/servlet/forum/viewthread_thread,6692
. Please close issue if another issue has been created for this in the meantime.
- - - 8< - - -
my colleague and I discovered a repeated standstill of our software in our test environment. While the first assumption was a programming error and/or wrong use of the DataNucleus middleware, after hours of searching it turned out that this is a deadlock problem caused by DataNucleus itself and started to occur after a recent update of the libraries to the 2.2.2 version within our software.
To our analysis the problem is that since version 2.1.4 (including 3.0.0 milestones), methods like begin(), commit(), rollback() of org.datanucleus.transaction.TransactionManager have become synchronized. This creates problems if two threads are trying to commit a transaction in the same moment. Thread A may win to lock the shared TransactionManager instance over a thread B. However, at the database the transaction associated with thread B may own row/table locks, which prevent the transaction of thread A to perform the commit. As the database does not have any knowledge of the DataNucleus synchronization, it cannot discover the cyclic dependency and cannot initiate the appropriate methods to defeat the deadlock, i.e. choosing a candidate and aborting its transaction. Instead, it lets the transaction of thread A wait until the transaction of thread B commits or rollbacks, which will never happen.
So it would be nice if you could review the respective class and eliminate the problem. If you need any further information, please let me know.
Edit: just found
in JIRA that was obviously the source for the "synchronized" change
- - - 8< - - -
Note that a potential solution was posted by another participant in the given forum thread.