[hibernate-issues] [Hibernate-JIRA] Closed: (HHH-4551) Query caching becomes very ineffective on conversations with extended sessions.

[Steve Ebersole (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Ebersole closed HHH-4551.
-------------------------------

    Resolution: Duplicate

HHH-5210

> 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira