[ 
https://issues.apache.org/jira/browse/OPENJPA-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497474#comment-13497474
 ] 

Rick Curtis commented on OPENJPA-2285:
--------------------------------------

This code fix introduced a regression where we would put invalid data in the 
cache and resulted in the ClassCastException while loading data in a subsequent 
request. This is very much an edge case as you needed to be executing a query 
which returned an Embeddable which had an eager relationship to another Entity 
which then referred back to the embedding Entity. @See the added ut/ Entity 
model for details.

Committing a code fix + new UT for this scenario to trunk and 2.2.x.
                
> L2 cache doesn't store FK(s) back into the cache when lazy loading data.
> ------------------------------------------------------------------------
>
>                 Key: OPENJPA-2285
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2285
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: datacache, performance
>    Affects Versions: 2.0.1, 2.1.1, 2.2.0, 2.3.0
>            Reporter: Rick Curtis
>            Assignee: Rick Curtis
>             Fix For: 2.3.0, 2.2.2
>
>
> I ran into a performance bug recently where we aren't caching data, but we 
> could be. The data that we aren't caching is when lazy loading an unowned 
> relationship .
> For instance, if we have the model Person <-> Address(LAZY, owner) and we 
> find Person, that data will get stored in the cache. Since Address owns the 
> relationship, we don't have the FK to cache(yet). Later we go to lazily load 
> the address and we need to issue a joined query to find the Address which 
> corresponds to our Person. Once that data has been loaded, we don't store the 
> FK back into the cache.
> With this JIRA I'm going to introduce a change that will make our runtime 
> re-cache the Person data when additional data is loaded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to