Issue Details (XML | Word | Printable)

Key: NUCCACHE-34
Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Minor Minor
Assignee: Unassigned
Reporter: Julian Schillinger
Votes: 0
Watchers: 2
Operations

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

Defining cacheable=false on inherited class in jdo file leads to incorrect class type returned

Created: 19/Jul/12 01:34 PM   Updated: 04/Jun/13 02:59 PM   Resolved: 24/Sep/12 02:50 PM
Component/s: javax.cache
Affects Version/s: 3.1.1
Fix Version/s: None

File Attachments: 1. Zip Archive 20120719 DNTestCaseCacheable.zip (6 kB)

Environment: OpenJDK, MySQL, Ubuntu Linux

Datastore: MySQL


 Description  « Hide
Scenario:
I have a parent class and two child classes which inherit the parent class. An instance of the parent class has a list which contains one instance of each child classes. One of the child instances references the other one via a field.
The jdo file defines the parent and the childs using "new-table" strategy. The field where one child instance references the other is in the default fetch group. All class definitions in the JDO file are set to 'cacheable="false"' as defined here: http://www.datanucleus.org/products/accessplatform_3_1/jdo/metadata_xml.html

How to reproduce problem:
Retrieve a persistent parent instance and then iterate through each child instance (form the parent's list field). The returned class name for the child instance referenced by the other child instance is as of the parent class, not the child class, ie the wrong information is returned.

How to work around:
1) Set the parent class to 'cacheable="false"' but the child classes to 'cacheable="true"'
2) Remove the field used by one child instance to reference the other from the default fetch group.
3) Switch off L1 cache.

Questions:
1) Does work around (1) above make sense conceptually. Ie would it make sense to set the parent to not-cacheable and the childs to cacheable?
2) If the parent is set to not-cacheable and the childs set to cacheable, is the object cached?

Proposed solution:
1) Kindly clarify on questions above and throw warning if (a) combination of JDO is not supported or (b) is illogical.
     or
2) Fix and return correct class type. (preferred)

Testcase:
Attached

Environment:
asm-4.0.jar
datanucleus-rdbms-3.1.0-m5.jar
datanucleus-enhancer-3.1.0-m2.jar
datanucleus-core-3.1.0-m5.jar
datanucleus-cache-3.1.1.jar
datanucleus-api-jdo-3.1.0-m3.jar
datanucleus-jdo-query-3.0.2.jar




Julian Schillinger added a comment - 19/Jul/12 01:51 PM
Testcase

Julian Schillinger made changes - 19/Jul/12 01:51 PM
Field Original Value New Value
Attachment 20120719 DNTestCaseCacheable.zip [ 11680 ]
Andy Jefferson added a comment - 24/Sep/12 02:50 PM
Don't see any error with this so who knows what you're seeing. Besides I don't see what it has to the third party L2 cache plugin, which is only used when defining to use the likes of Coherence, EHCache etc.

Andy Jefferson made changes - 24/Sep/12 02:50 PM
Status Open [ 1 ] Resolved [ 5 ]
Resolution Cannot Reproduce [ 5 ]
Andy Jefferson made changes - 24/Sep/12 02:50 PM
Status Resolved [ 5 ] Closed [ 6 ]
Cyril Bouteille added a comment - 04/Jun/13 01:44 AM
Andy, there's definitely something going on with setting cacheable on subclasses.
We experienced a related performance issue where DN 3.1.2 is doing L2 GETs of a cacheable="false" subclass which makes no sense.
I tried Julian's workaround and it fixed the issue FYI.

Andy Jefferson added a comment - 04/Jun/13 02:59 PM
Cyril, I refer you to my comments above and the need for a testcase to demonstrate something (with recent releases).

Reporter also raised this on the 3rd party caching plugin yet his test does nothing of the sort.