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-682
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Chris Colman
Votes: 0
Watchers: 0

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

Deadlock while detaching all on commit while another thread attempts to get object

Created: 21/Mar/11 08:05 AM   Updated: 09/May/11 09:58 AM   Resolved: 07/Apr/11 08:43 AM
Component/s: Code Structure
Affects Version/s: 3.0.0.m2
Fix Version/s: None

File Attachments: 1. File (3 kB)

Environment: Windows XP, Oracle XE, IntelliJ, JVM 1.5

Datastore: Oracle
Severity: Production

 Description  « Hide

Thread A:

Background thread running a Job Manager.

Thread B:

A job has finished which invokes another background thread that sends off an email notification. It accesses some persistent objects to retrieve email server name and user credentials.

The application was running for a couple of days before this occurred so it's reproducibility via a unit test maybe somewhat hard to accomplish but hopefully the stack dump may provide some light as to where the deadlock occurred.

It appears as though the 'detach all on commit' method is executing in the first thread and attempts to synchronize in a backed List method at the same time the second thread is attempting to retrieve a persistent object. file is attached.

jobmgr.JobMgrProxy@1bc6ed3@3152, prio=5, in group 'main', status: 'waiting for monitor entry'
  java.lang.Thread.State: BLOCKED
                blocks Thread-139535@11298
                waiting for Thread-139535@11298
                  at org.datanucleus.state.JDOStateManagerImpl.detach(
                  at org.datanucleus.ObjectManagerImpl.performDetachAllOnTxnEnd(
                  at org.datanucleus.ObjectManagerImpl.postCommit(
                  at org.datanucleus.ObjectManagerImpl$2.transactionCommitted(
                  at org.datanucleus.TransactionImpl.internalPostCommit(
                  at org.datanucleus.TransactionImpl.commit(
                  at org.datanucleus.api.jdo.JDOTransaction.commit(
                  at jobmgr.JobMgr.process(
                  at jobmgr.TaskProxy.process(

Thread-139535@11298, prio=5, in group 'main', status: 'waiting for monitor entry'
  java.lang.Thread.State: BLOCKED
                blocks com.thales.ctip.ipis.model.jobmgr.JobMgrProxy@1bc6ed3@3152
                waiting for jobmgr.JobMgrProxy@1bc6ed3@3152
                  at org.datanucleus.ObjectManagerImpl.findObjectProvider(
                  at com.acme.performNotify(
                  at com.acme.notifications.EmailNotifier$1.execute(

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 28/Mar/11 04:06 PM
i see nothing implying that DN is deadlocking itself. A PM is not thread-safe, so any "detach" in thread 1 and "find" in thread 2 will be working on different PM/ObjectManagerImpl/Transaction and consequently objects. JobMgrProxy is your object

Chris Colman added a comment - 07/Apr/11 04:14 AM
You can close/delete this issue as it is now resolved - not a DataNucleus problem - put it down to user error :)

I discovered that someone had inadvertently passed a persistent instance from one background thread to another - each thread has its own PM so that was never going to turn out well.