In this chapter, we discussed the Hibernate cache architecture, scope, strategies, cache modes, and cache metrics. One of the reasons why Hibernate is a powerful mapping tool is its ability to reduce the number of database trips, and caching the persistent data is one of the mechanisms that help this.

You have learned about first- and second-level cache structures. You also learned about query cache. You should never rely on a cache to solve performance problems in your application. However, you should always take advantage of features that will help you achieve better performance.

The use of cached data may result in unexpected behavior in your application if not designed correctly. This chapter provided enough information to help you understand the internals of Hibernate cache. By now, you should know that if your data store is shared between multiple applications, you should not store any critical data in the second-level cache, and you should be mindful of the fact that data may be stale.

Furthermore, we discussed that special care needs to be taken with working with query cache as it may cause unnecessary database hits.

Luckily, Hibernate offers ways to configure a cache both at deployment and runtime. You should take advantage of this. You can simply set cache.use_second_level_cache and cache.use_query_cache to false and restart your application. This is helpful when you are trying to eliminate the Hibernate cache as a possible culprit for mysterious issues.

Finally, it is useless to use the second-level cache without monitoring its utilization. Collecting and generating a cache utilization report is important to ensure that your application is in fact gaining in performance when the cache is enabled.