Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Date: Wed, 28 Aug 2013 15:16:52 +0000 (UTC)
From: "Kevin Sutter (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Message-ID: <JIRA.12659627.1374689408837.47257.1377703012635@arcas>
In-Reply-To: <JIRA.12659627.1374689408837@arcas>
References: <JIRA.12659627.1374689408837@arcas>
Subject: [jira] [Commented] (OPENJPA-2414) FinderCache does not consider
 active Fetch Groups/FetchPlan added Fields
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kevin Sutter commented on OPENJPA-2414:
---------------------------------------

Oh sure, Thanks Jody for hauling me into this discussion...  :-)

I will agree that the current usage scenario was not intuitive or documented.  And, since we have customers hitting this condition of accidentally caching the "wrong" SQL, I agree that we need to do something in the service streams to resolve the issue.  And, considering the 80/20 rule, it seems that erring on the default/conservative side definitely hits the 80% side of the market.

That all being said, Pinaki does have a valid point that we are now alienating users that use fetch plans from using the FinderCache.  But, that is also consistent with Pinaki's direction to have the application control whether these generated SQL's should be cached or not.  We're just making that decision for them.

Also, does this change in behavior have any impact on the normal callpath from a performance perspective?  Pinaki is hinting that it will affect performance.  If we are doing additional processing on every generated SQL and access to the FinderCache, then are we negating the benefits of the cache?

One alternative is to modify the FinderCache so that it could take the FetchPlan settings into account.  Whether this extra processing would offset the benefit of the cache would have to be determined.  Regardless, this is too big of an effort for the service streams.  I would suggest creating a sub-JIRA feature for this effort so that we have it on the books.  But, stick with this conservative approach until this sub-feature is resolved.

That's my two cents worth.  But, don't just re-close this JIRA without coming to some type of agreement.  I've posted a few questions that should be discussed and resolved.  Thanks. 
                
> 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