Over a million developers have joined DZone.

All About Hibernate Second Level Cache

DZone's Guide to

All About Hibernate Second Level Cache

· Java Zone
Free Resource

The single app analytics solutions to take your web and mobile apps to the next level.  Try today!  Brought to you in partnership with CA Technologies

Recently I experimented with Hibernate Cache. In this post I would like to share my experience and point out some of the details of Hibernate Second Level Cache. On the way I will direct you to some articles that helped me implement the cache. Let's get started from the ground.

Caching in hibernate

Caching functionality is designed to reduce the amount of necessary database access. When the objects that are cached reside in memory. You have the flexibility to limit the usage of memory and store the items in disk storage. The implementation will depend on the underlying cache manager. There are various  flavors of caching available, but it is better to cache non-transactional and read-only data.

Hibernate provides 3 types of caching.

1. Session Cache

    The session cache caches objects within the current session. It is enabled by default in Hibernate. Read more about  Session Cache . Objects in the session cache reside in the same memory location.

2. Second Level Cache

     The second level cache is responsible for caching objects across sessions. When this is turned on, objects will first be searched in the cache and if they are not found, a database query will be fired. Read here on how to implement  Second Level Cache. Second level cache will be used when the objects are loaded using their primary key. This includes fetching of associations. Second level cache objects are constructed and reside in different memory locations.

3. Query Cache

Query Cache is used to cache the results of a query. Read here on how to implement query cache. When the query cache is turned on, the results of the query are stored against the combination query and parameters. Every time the query is fired the cache manager  checks for the combination of parameters and query. If the results are found in the cache, they are returned, otherwise a database transaction is initiated.  As you can see, it is not a good idea to cache a query if it has a number of parameters, because then a single parameter can take a number of values. For each of these combinations the results are stored in the memory. This  can lead to extensive memory usage.

Finally, here is a list of good articles written on this topic, 

1. Speed Up Your Hibernate Applications with Second-Level Caching
2. Hibernate: Truly Understanding the Second-Level and Query Caches
3.  EhCache Integration with Spring and Hibernate. Step by Step Tutorial
4. Configuring Ehcache with hibernate

CA App Experience Analytics, a whole new level of visibility. Learn more. Brought to you in partnership with CA Technologies.


Published at DZone with permission of Manu Pk. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}