[hibernate-issues] [Hibernate-JIRA] Assigned: (HHH-5210) Query Cache effective only after closing the session that created the cache

Query Cache effective only after closing the session that created the cache --------------------------------------------------------------------------- Key: HHH-5210 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5210 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.5.x Reporter: Strong Liu Assignee: Steve Ebersole Attachments: hhh-5210.patch When using a query which is marked as cacheable, Hibernate caches both the query and the timestamp in the cache, but uses two different timestamps for that. When retrieving a query from the cache, it first compares the timestamp of the cached query with the timestamp of the current session (UpdateTimestampsCache.isUpToDate()): if ( lastUpdate.longValue() >= timestamp.longValue() ) { return false; } The problem is that the timestamp for the current session is always lower than cache's timestamp if the cache was created with the same session, causing the result of the method to be "false", discarding the cache results and hitting the database. It's not clear where the bug is, but it's worth looking at some considerations: 1) Why is it comparing the cache's timestamp with session's timestamp? The cache itself can expire the data via timeout and Hibernate should expire the data if any relevant table was changed (both are happening). Besides, I wasn't able to think of a single use case where the cached data could be considered "outdated" just because its timestamp is higher than the current session's timestamp (meaning that they are newer than the session). 2) The javadoc for the SessionImplementor.getTimestamp() says: "System time before the start of the transaction" So, someone consuming this method can assume that this timestamp is related to the transaction. If the timestamp was related to the transaction, then the cache's timestamp would never be higher than session's. Then, this comparison would make sense, to not return something which would never happen and is probably wrong. So, it's up to the developers to decide what's wrong: - JavaDoc + the logic to get a timestamp which is used when creating the query cache - getTimestamp() value + UpdateTimestampsCache.isUpToDate logic + other places relying in the wrong return value