[
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.
