Query result sets may also be cached. This is only useful for queries that are run frequently with the same parameters. To use the query cache you must first enable it:
hibernate.cache.use_query_cache true
This setting causes the creation of two new cache regions - one holding cached query
result sets (org.hibernate.cache.StandardQueryCache
), the other
holding timestamps of the most recent updates to queryable tables
(org.hibernate.cache.UpdateTimestampsCache
). Note that the query
cache does not cache the state of the actual entities in the result set; it caches
only identifier values and results of value type. So the query cache should always be
used in conjunction with the second-level cache.
Most queries do not benefit from caching, so by default queries are not cached. To
enable caching, call Query.setCacheable(true)
. This call allows
the query to look for existing cache results or add its results to the cache when
it is executed.
If you require fine-grained control over query cache expiration policies, you may
specify a named cache region for a particular query by calling
Query.setCacheRegion()
.
List blogs = sess.createQuery("from Blog blog where blog.blogger = :blogger") .setEntity("blogger", blogger) .setMaxResults(15) .setCacheable(true) .setCacheRegion("frontpages") .list();
If the query should force a refresh of its query cache region, you should call
Query.setCacheMode(CacheMode.REFRESH)
. This is particularly useful
in cases where underlying data may have been updated via a separate process (i.e.,
not modified through Hibernate) and allows the application to selectively refresh
particular query result sets. This is a more efficient alternative to eviction of
a query cache region via SessionFactory.evictQueries()
.