Look at chapter 14.6 of the documentation. The regions and the way to control them are defined pretty exhaustively there. Here is an excerpt
14.6. The Query Cache
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 by setting the property hibernate.cache.use_query_cache=true. This causes the creation of two cache regions - one holding cached query result sets (net.sf.hibernate.cache.QueryCache), the other holding timestamps of most recent updates to queried tables (net.sf.hibernate.cache.UpdateTimestampsCache). Note that the query cache does not cache the state of any entities in the result set; it caches only identifier values and results of value type. So the query cache is usually 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 may call Query.setForceCacheRefresh() to true. This is particularly useful in cases where underlying data may have been updated via a seperate process (i.e., not modified through Hibernate) and allows the application to selectively refresh the query cache regions based on its knowledge of those events. This is an alternative to eviction of a query cache region. If you need fine-grained refresh control for many queries, use this function instead of a new region for each query.
|