Details
-
Sub-task
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.0.0-M3
-
None
-
None
Description
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