Issue Details (XML | Word | Printable)

Key: CORE-3558
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Chris Colman
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
JPOX Core (ARCHIVED)

Frequent exception when reattaching a detached object refering to a common object

Created: 18/Mar/11 07:22 AM   Updated: 21/Mar/11 01:14 PM
Component/s: JDO
Affects Version/s: None
Fix Version/s: None

File Attachments: 1. Zip Archive reattachWithCommonRelatedObjectEx.zip (12 kB)

Environment:
Windows XP
HSQLDB in server (file) mode.

Datastore: HSQL
Severity: Production


 Description  « Hide
With two classes A, Base where
'Base' 1-to-many (bidir) 'A'

Create two A objects (storedA, storedA1), both refer to a single Base object which has a collection of references back to the A's.
Persist, commit Txn

Auto detach on commit is enabled

makePersistent(storedA); // works fine
makePersistent(storedA1);// approximately 25% of the time the following exception is thrown:

INFO: Exception thrown
Attempt to attach object "org.datanucleus.test.A@13816e0" to persistence yet another persistent object with this identity already exists enlisted in this transaction
org.datanucleus.exceptions.NucleusUserException: Attempt to attach object "org.datanucleus.test.A@13816e0" to persistence yet another persistent object with this identity already exists enlisted in this transaction
at org.datanucleus.ObjectManagerImpl.attachObject(ObjectManagerImpl.java:2011)
at org.datanucleus.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1580)
at org.datanucleus.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1439)
at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:726)
at org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:751)

If you run the test case about 4-5 times you should see the exception occur at least once.

I'm not sure if the exception is to be expected or not - but surely it shouldn't be a case of occurring sometimes and not occurring others.

Sort Order: Ascending order - Click to sort in descending order
Chris Colman added a comment - 18/Mar/11 07:32 AM - edited
BTW: This happens with the latest nightly build of DN 3.0.0-m3.

Interesting parts of the datanucleus.properties file are:

javax.jdo.option.Optimistic=true
javax.jdo.option.RetainValues=false
javax.jdo.option.RestoreValues=true
javax.jdo.option.NontransactionalRead=false

datanucleus.DetachAllOnCommit=true
datanucleus.CopyOnAttach=false

# Seems to work ok if CopyOnAttach is set to true and we use

storedA = pm.makePersistent(storedA);
storedA1 = pm.makePersistent(storedA1);

instead of not copying on attach.

Andy Jefferson added a comment - 21/Mar/11 09:41 AM
i don't believe in non-deterministic behaviour when only using 1 thread. if you're using the l2 cache then you can easily pin things in the cache

Chris Colman added a comment - 21/Mar/11 01:14 PM
Do you have any idea as to why would it be completely deterministic (and successful) if CopyOnAttach=true but not if CopyOnAttach=false (i.e. fails 25% of the time)? - both with just a single thread.