Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <1109728652.570681269920727194.JavaMail.jira@brutus.apache.org>
Date: Tue, 30 Mar 2010 03:45:27 +0000 (UTC)
From: "Rick Curtis (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-1603) Decouple the QueryCache from the
 DataCache
In-Reply-To: <1659023097.557801269892827392.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rick Curtis commented on OPENJPA-1603:
--------------------------------------

Committed rev. 928968 to the 2.0.x branch.

I had to make a couple last minute changes to the two new Entities that were added with this JIRA to get all of the tests to pass. Mike -- if you don't like what I've done, feel free to change/update the Entities properly.

Another note, currently to get a reference to the QueryCache you need to go through the DataCacheManager. Ideally you wouldn't need to do this, but I'm trying to limit my changes to the bare essentials to limit additional churn.

> Decouple the QueryCache from the DataCache
> ------------------------------------------
>
>                 Key: OPENJPA-1603
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1603
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: datacache
>    Affects Versions: 2.0.0
>            Reporter: Rick Curtis
>            Assignee: Rick Curtis
>             Fix For: 2.0.0
>
>
> In doing some testing I have found that there is a valid use case where one would want to use the query results cache (openjpa.QueryCache), but not the DataCache. I'm using this JIRA to remove the dependency between these two caches.
> The gist of this change is that the QueryCache will now talk with the StoreContext to see if the results of a cached query are contained in the L1 cache OR by any of the DelegatingStoreManager's cache. The default JDBCStoreManager and the XMLStoreManager both do not have any concept of a cache and will always not have any cached results.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.