Query caching becomes very ineffective on conversations with extended sessions. ------------------------------------------------------------------------------- Key: HHH-4551 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4551 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: 3.3.2 GA Reporter: Guenther Demetz Hibernate's query cache (hibernate.cache.use_query_cache) always takes the initial session timestamp for storing the result-set timestamp. --------------------------------------------- StandardQueryCache.java (put-method): ... Long ts = new Long( session.getTimestamp() ); ... cacheable.add( ts ); --------------------------------------------- When extending a session for a whole conversation (Book "Java Persistence with Hibernate" chapter. 11.2.3), the sessions initial timestamp get's soon rather deferred to the time a new query result set is produced actually. Immagine a long conversation which lasts more than 5 minutes. This leads to the effect, that often still valid result-set-cache entries are considered not up-to-date because of a flushed update action occured during the conversation. Furthermore the new obtained query-resultset (note that this query now considers the last update!) is subsequently again put in cache still with the original and outdated sessions-timestamp: That's for the birds ! Proposal: Why not take the current timestamp instead? For example calling: Long ts = new Long( cacheRegion.nextTimestamp()); best regards Guenther D. -- 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