[
https://issues.apache.org/jira/browse/OPENJPA-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pinaki Poddar reopened OPENJPA-2414:
------------------------------------
This change is not align with the original intent. The idea of caching a finder
query is *not* related to whether *only* default Fetch Plan is being used. The
idea is (or at least was) that if *anything* (fetch plan, lock mode) that
impact a target SQL, the application *must* bypass the cache. This design
decision is deliberate from a performance perspective. Because under such
immutablity assumption, the runtime does not have to spend any extra
computation cycle to use the cache. While if the application always knows when
it changes something that impacts the target SQL, so it can always bypass the
finder cache. This choice favors the common 80% use case over the less common
use case where the application mutates *something* that impacts a target SQL.
This issue is reopened. Please either start a discussion if you are suggesting
an alternative design/usage or revert to "user-is-reponsible" model of usage
which was the original intent.
> FinderCache does not consider active Fetch Groups/FetchPlan added Fields
> ------------------------------------------------------------------------
>
> Key: OPENJPA-2414
> URL: https://issues.apache.org/jira/browse/OPENJPA-2414
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.3.0, 2.2.3
> Reporter: Jody Grassel
> Assignee: Jody Grassel
> Fix For: 2.1.2, 2.3.0, 2.2.1.1, 2.2.3
>
>
> The FinderCache retains a Map, associating a ClassMapping with a FinderQuery.
> However, this cache does not factor in the characteristics of the FetchPlan
> that was active when a mapping is created, nor does it factor them to
> determine if a cache hit is appropriate. This causes the find() operation to
> perform the same SQL as the first time it was executed, regardless of changes
> to the active FetchPlan afterwards.
--
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
