Caching is all about application performance optimization and it sits between your application and the database to avoid the number of database hits as many as possible to give a better performance. I am going to show how we can use ehcache as hibernate second level entity cache in clustered environment.
Prerequisite: Knowledge of EHcache, JGroups and Jconsole.
In context of multiple application server, you need to replicate ehcache among them for consistency. Ehcache modules for the following replicated caching mechanisms are available:
For more information go through http://www.ehcache.org/documentation/2.8/replication.
Here, I am going with JGroups UDP Multicast. Below are steps to configure Ehcache as hibernate second level entity cache using Jgroups for cluster environment.
Add following dependency in pom.xml.
Second level cache is disabled by default in hibernate, so we would need to enable it and add some configurations as shown below to get it working.
<property name="hibernate.cache.provider_class" value="net.sf.ehcache.hibernate.SingletonEhCacheProvider"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.generate_statistics" value="true"/>
Configure Hibernate Entities to use Second-Level Caching. We can do this using annotation as shown below.
@org.hibernate.annotations.Cache(usage = org.hibernate.annotations.CacheConcurrencyStrategy.READ_WRITE)
We can use following values for cache strategy:
This sets the cache region as a read only cache, and this means it can be very performant as the cache doesn't have to worry about locking. If you try to modify any of these objects though, you will get an exception.
This allows you to modify cacheable objects, but the cache provider doesn't need to implement a strict lock on the cache. This means there is a potential for stale objects (ie one transaction has modified an object, but another object picks up the old version of the object from the cache). Choose this for writable objects, but only if you don't care about stale data.
The "safest" but least performant option. The cache provider will lock the cache when the object is updated, ensuring that all transactions will see the most up to date version.
EHCache comes with some defaults out of the box when you configure caching. But you can create your own configuration. You can easily do this by providing a file name ehcache.xml on the classpath. Below is sample configuration ehcache.xml.
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true" monitoring="autodetect" dynamicConfig="true">
That’s It. Cache is configured…!!
Does your cache work?
When you have finally configured your cache, you want to know if it works. Of course you can check entities are cached or not, hit and miss ratio for them. You can export Mbean for that and see statistics in Jconsole for each entity you marked as cacheable.
For professional paid support, you may contact us at firstname.lastname@example.org .