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)

Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Andy Jefferson
Votes: 0
Watchers: 1

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

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 20/Apr/10 08:14 AM
SVN trunk and branches/2.0 have this

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

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!