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