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: Cannot Reproduce
Priority: Minor Minor
Assignee: Unassigned
Reporter: Julian Schillinger
Votes: 0
Watchers: 2

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 (6 kB)

Environment: OpenJDK, MySQL, Ubuntu Linux

Datastore: MySQL

 Description  « Hide
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:

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.

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.
2) Fix and return correct class type. (preferred)



Sort Order: Ascending order - Click to sort in descending order
Julian Schillinger added a comment - 19/Jul/12 01:51 PM

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.

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.