Issue Details (XML | Word | Printable)

Key: NUCRDBMS-371
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Andy Jefferson
Votes: 0
Watchers: 1
Operations

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

Return of object from query places object in L2 cache before setting version

Created: 20/Apr/10 08:07 AM   Updated: 26/Apr/10 03:38 PM   Resolved: 20/Apr/10 08:14 AM
Component/s: Queries
Affects Version/s: 2.0.0.release, 2.0.1, 2.0.2, 2.0.3, 2.1.0.m1
Fix Version/s: 2.0.4, 2.1.0.m2


 Description  « Hide
When we do a query and iterate through the results objects are instantiated and put into the L2 cache at that point. We then set the version after. This means that any object put in the L2 cache doesn't have its version set and can cause subsequent problems, so we must set the version during the instantiation

Andy Jefferson added a comment - 20/Apr/10 08:14 AM
SVN trunk and branches/2.0 have this

Andy Jefferson made changes - 20/Apr/10 08:14 AM
Field Original Value New Value
Status Open [ 1 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Chris Colman added a comment - 23/Apr/10 11:50 PM
Could this be the cause of the 'object version not set in memory' issue?

Andy Jefferson added a comment - 24/Apr/10 09:06 AM
The issue here was reproduced in just 5 mins of generating a testcase, present at the end of
http://datanucleus.svn.sourceforge.net/viewvc/datanucleus/test/accessplatform/trunk/test.jdo.datastore/src/test/org/datanucleus/tests/OptimisticTest.java?revision=9620&view=markup

Whether that is your situation only you can answer

Chris Colman added a comment - 24/Apr/10 09:17 AM
In my scenario I wasn't explicitly getting the object id but when I later committed my transaction I guess the fact that the version was not set in memory was the cause of my "version not set in memory" exception.

Given that it was related to optimistic locking I was thinking it must have been related to two separate PMs updating the same object from different threads. I did however see it happening in cases where it appeared as though only a single PM would have been accessing the object - which was playing with my head: an optimistic verification exception when only one thread was updating the object?

Anyway, it's great to see this one nailed!

Andy Jefferson made changes - 26/Apr/10 03:38 PM
Status Resolved [ 5 ] Closed [ 6 ]