[
https://issues.apache.org/jira/browse/OPENJPA-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752001#comment-13752001
]
Jody Grassel commented on OPENJPA-2414:
---------------------------------------
Please show me the location in the OpenJPA documentation that supports your
position as "original intent" is meaningless if it's not well documented. It's
sure not intuitive and it's going to fool a lot of applications consuming
OpenJPA (which has already happened, hence this going into a service branch.)
If you're asserting that OpenJPA's behavior before the fix is correct and in
"alignment with original intent", then you're going to have a race condition
where the first em.find() sets the sql for every em.find() that comes after
(look at the new tests added that look for this.) In a J2EE application with
many entry points, whoever first gets to set the Fetch Plan forever associates
with the characteristics of that fetch plan with every future
em.find(MyEntity.class) -- you will have a race condition. A call to em.find()
with a default fetch plan with a FinderCache initialized with an entry with a
non default fetch plan will execute the non-default fetch plan sql because that
is what is cached. I think everyone can agree that is a BAD thing.
The change this JIRA makes is quite simple: only SQL generated by the default
fetch plan for the persistence context (be it just "default" or a new default
as set by pu properties) is what's cached. If an em.find() is performed with a
fetch plan that is not equal to the default, then it will not go to the cache
and instead build the SQL as dictated by the current fetch plan. This way an
altered fetch plan is honored (instead of ignored) each time it is changed, and
is safe for consumption in a service stream. 80% of most OpenJPA users
probably do not touch FetchPlans, so this will not impact them.
I have considered making the FinderCache FetchPlan smart for trunk, that will
be done in a future JIRA.
I will discuss this with Kevin tomorrow morning, and if he still agrees with my
change I will re-close this JIRA.
> 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
