DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Key: NUCCORE-714
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Testcase Required Testcase Required
Assignee: Unassigned
Reporter: Klaus Malorny
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
DataNucleus Core

severe deadlock with org.datanucleus.transaction.TransactionManager 2.1.4 and up

Created: 26/May/11 09:15 AM   Updated: 01/Aug/11 10:23 AM   Resolved: 16/Jul/11 08:27 AM
Component/s: None
Affects Version/s: 2.1.4, 2.2.0.m1, 2.2.0.m2, 2.2.0.m3, 2.2.0.release, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 3.0.0.m1, 3.0.0.m2, 3.0.0.m3
Fix Version/s: 3.0.0.m4

Forum Thread URL: severe deadlock with org.datanucleus.transaction.TransactionManager 2.1.4 and up
Datastore: PostgreSQL
Severity: Production

 Description  « Hide
This issue shall represent and track the problem I reported in the forum at,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 NUCCORE-596 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.

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 26/May/11 09:26 AM
Actually if you check your facts, these methods are NOT synchronised in 3.0m4. Used that?

Andy Jefferson added a comment - 15/Jun/11 10:26 AM
3.0 m4 and 3.0 m5 have not had any such sync blocks and no way of reproducing so marking as incomplete until checked against those releases and/or a testcase provided

Andy Jefferson added a comment - 16/Jul/11 08:27 AM
Changes were made several releases ago, and no reported problems, therefore marking as fixed