You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Xiaoqin Feng (JIRA)" <ji...@apache.org> on 2009/12/28 19:53:29 UTC
[jira] Commented: (OPENJPA-1448) Synching of DataCache with
QueryCache outside of a transaction
[ https://issues.apache.org/jira/browse/OPENJPA-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794879#action_12794879 ]
Xiaoqin Feng commented on OPENJPA-1448:
---------------------------------------
I am on vacation from 12/20/2009 Â to 12/26/2009.
If you have any question on deployment and JEE bugs, please contact Saurabh Arora or my manager Maruthi Nuthikattu.
For emergency, contact me at 925-209-5517.
> Synching of DataCache with QueryCache outside of a transaction
> --------------------------------------------------------------
>
> Key: OPENJPA-1448
> URL: https://issues.apache.org/jira/browse/OPENJPA-1448
> Project: OpenJPA
> Issue Type: Sub-task
> Components: datacache
> Affects Versions: 2.0.0-M3
> Reporter: Kevin Sutter
> Priority: Minor
>
> One of the tests (CacheTest.testQueryImplicitEvictions) re-enabled for the parent JIRA (openjpa-1443) expected that the DataCache would automatically synch up with the QueryCache, even outside of a transaction. This test would first load up the DataCache with Entity instances. Then, a Query would be created and executed against these Entities to create an entry in the QueryCache. Then, using implicit eviction processing, those target Entities were removed from the DataCache. The expectation was that this implicit eviction would also clean up the QueryCache so that the Query and Results were no longer present.
> It doesn't look like our synchronization between the DataCache and QueryCache work that way. We will do synchronization when a "dirty" transaction completes. That is, if you have updated or deleted Entities that exist in the DataCache, when that transaction completes, we will do a synch with the QueryCache to remove stale Queries and Results. But, we don't do this synchronization on every eviction.
> Maybe Kodo did and that's why this testcase exists? Not sure. To be honest, I'm concerned about this type of synchronization from an overhead perspective. If every eviction required us to scour the QueryCache for a potential stale Result, we might be chewing up a lot of resources. But, since this previously disabled testcase expected this capability, I thought I would write a low-priority JIRA to track the issue. Here are my comments from the CacheTest.testQueryImplicitEvictions method:
> /*
> * Not a valid test... At least not with the current implementation...
> *
> * Just removing items from the DataCache (as done via the previous loop) is not sufficient
> * to remove the entries from the QueryCache. Currently, this notification is done at the end
> * of a transaction after inserts, updates, and deletes have been performed. Then, the
> * updateCaches() method is invoked on the DataCacheStoreManager which will flow the request to
> * the QueryCache. With no direct updates to the "Entities of interest", then there's nothing to
> * flow over to the QueryCache for cleanup. Even putting the above loop within a transaction is
> * not sufficient, since there have been no updates to the "Entities of interest".
> */
> // em = factory.createEntityManager();
> // broker = JPAFacadeHelper.toBroker(em);
> // q = broker.newQuery(JPQLParser.LANG_JPQL, "Select a FROM "
> // + CacheObjectJ.class.getSimpleName()
> // + " a where a.str = 'h'");
> // try {
> // assertInCache(q, null);
> // }
> // catch (AssertionFailedError e) {
> // bug(626, "query cache invalidation is broken");
> // }
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.