Recently I have experimented with hibernate cache. In this post I would like 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 reduces the amount of necessary database access. When the objects are cached they resides 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 is better to cache non-transactional and read-only data.Hibernate provides 3 types of caching.
1. Session Cache
The session cache caches object within the current session. It is enabled by default in Hibernate. Read more about Session Cache. Objects in the session cache resides 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 be first searched in 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. In case of second level cache the objects are constructed and hence all of them will 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 other wise a database transaction is initiated. As you can see, it is not a good idea to cache a query if it has number of parameters or a single parameter can take number of values. For each of this combination 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
Good post. However this line " Objects in the session cache resides in the same memory location"
ReplyDeleteseems to be misleading. There is nothing like "same memory location". The actual concept is that as long as a session is active, an entity has only one instance in that session and it is the one that is returned if asked for. It's crucial for hibernate to maintain only one representation of an entity in a session so that only the changes in that one instance is tracked and updated.
Thank you for the clarification, what I meant that both object refers to the same instance. This is important since in second level cache two objects can contain same data but will be different instance. So, in the same session objects will follow "==" and "equals" check but where in is 2nd level cache they will follow only "equals" rule.
DeleteInformative post. I have a doubt on second level cache's behaviour. What will happen to the data present in the cache when one of the entity gets deleted from the cache?
ReplyDeleteWhat we are observing is that, when we delete an entity all other entities from the cache gets evicted. How can i prevent this from happening?
You can set the interval at which you want to update your cache, so that it stays updated with the contents on the DB. May be you can get better answers from stackoverflow.com
Delete