Chapter 21. Improving performance

Example 21.10. Second-level cache eviction via SessionFactoty.evict() and

SessionFacyory.evictCollection()

sessionFactory.evict(Cat.class, catId); //evict a particular Cat sessionFactory.evict(Cat.class); //evict all Cats sessionFactory.evictCollection("Cat.kittens", catId); //evict a particular collection of kittens sessionFactory.evictCollection("Cat.kittens"); //evict all kitten collections

The CacheMode controls how a particular session interacts with the second-level cache:

•CacheMode.NORMAL: will read items from and write items to the second-level cache

•CacheMode.GET: will read items from the second-level cache. Do not write to the second-level cache except when updating data

•CacheMode.PUT: will write items to the second-level cache. Do not read from the second-level cache

•CacheMode.REFRESH: will write items to the second-level cache. Do not read from the secondlevel cache. Bypass the effect of hibernate.cache.use_minimal_puts forcing a refresh of the second-level cache for all items read from the database

To browse the contents of a second-level or query cache region, use the Statistics API:

Example 21.11. Browsing the second-level cache entries via the Statistics

API

Map cacheEntries = sessionFactory.getStatistics()

.getSecondLevelCacheStatistics(regionName)

.getEntries();

You will need to enable statistics and, optionally, force Hibernate to keep the cache entries in a more readable format:

Example 21.12. Enabling Hibernate statistics

hibernate.generate_statistics true

hibernate.cache.use_structured_entries true

21.4. The Query Cache

Query result sets can also be cached. This is only useful for queries that are run frequently with the same parameters.

340

Enabling query caching

21.4.1. Enabling query caching

Caching of query results introduces some overhead in terms of your applications normal transactional processing. For example, if you cache results of a query against Person Hibernate will need to keep track of when those results should be invalidated because changes have been committed against Person. That, coupled with the fact that most applications simply gain no benefit from caching query results, leads Hibernate to disable caching of query results by default. To use query caching, you will first need to enable the query cache:

hibernate.cache.use_query_cache true

This setting creates two new cache regions:

•org.hibernate.cache.StandardQueryCache, holding the cached query results

•org.hibernate.cache.UpdateTimestampsCache, holding timestamps of the most recent updates to queryable tables. These are used to validate the results as they are served from the query cache.

Important

If you configure your underlying cache implementation to use expiry or timeouts is very important that the cache timeout of the underlying cache region for the UpdateTimestampsCache be set to a higher value than the timeouts of any of the query caches. In fact, we recommend that the the UpdateTimestampsCache region not be configured for expiry at all. Note, in particular, that an LRU cache expiry policy is never appropriate.

As mentioned above, most queries do not benefit from caching or their results. So by default, individual queries are not cached even after enabling query caching. To enable results caching for a particular query, call org.hibernate.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.

Note

The query cache does not cache the state of the actual entities in the cache; it caches only identifier values and results of value type. For this reaso, the query cache should always be used in conjunction with the second-level cache for those entities expected to be cached as part of a query result cache (just as with collection caching).

341