Distributed QueryCache does not evict - UpdateTimestampsCache has null entry
----------------------------------------------------------------------------
Key: HHH-3734
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3734
Project: Hibernate Core
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.1
Environment: Centos 64, Hibernate 3.3.1 + ehcache1.5, multiple Tomcat virtual
hosts - CMS app interacting with user facing app (high volume)
Reporter: Eric Ellis
Priority: Minor
Attachments: hibernate-core.patch
I've attached a patch that resolves the following distributed caching issue:
-App1 (user facing website)
-App2 (cms)
1. App1 calls: StandardQueryCache.cacheRegion.put() placing an HQL query in cache
referencing table "A"
2. App2 makes an update to the entity representing table "A"
3. EHCache on App2 broadcasts an "UPDATE" message to update the
UpdateTimestampsCache for table "A"
4. App1 receives the "UPDATE" message from App2 but ignores it because the
UpdateTimestampsCache for App1 does not contain an entry for table "A"
5. App1 holds onto it's originally cached value and does not reflect the update that
has taken place
Basically, the user facing application is not receiving CMS updates for HQL queries when
distributed. This is because the QueryCache API does not pass the Set of
"spaces" and the StandardQueryCache does not populate the UpdateTimestampsCache
with an initial entry when an HQL query is cached.
The attached patch resolves this issue by simply adding an old (before now) timestamp to
the UpdateTimestampsCache for each "space", if null, when a query is cached.
This code is currently running on a production cluster of 7, 8-CPU machines and is working
perfectly. The downside is that now that the cache is evicting HQL queries we're
finding that we have problems with how often our caches are being evicted. But at least
now the data is correct.
Because this patch introduces an API change to QueryCache I don't expect that the fix
will be accepted.
NOTE: I did not attempt to address the suggested locking issues
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira