openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jody Grassel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OPENJPA-2414) FinderCache does not consider active Fetch Groups/FetchPlan added Fields
Date Wed, 28 Aug 2013 01:34:52 GMT

    [ 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

Mime
View raw message