Open Gitter Chat
FREE, online, self-paced, learning for Hazelcast at the Hazelcast Training Center. Learn More »


Hibernate 2nd Level Cache

Caching solutions are needed to ensure that data is in the right place when it’s needed for optimal performance.

Hibernate organizes caching into First Level and Second Level caches.

First-level caches

Hibernate ships with a first-level cache associated with the Session object that principally reduces the number of SQL queries within a given transaction. For example, multiple changes will only result in a single update statement.

Second-level cache

Hibernate also offers the opportunity to plug-in a second-level cache. This cache associates with the Session Factory object. This means that the cache is not restricted to a single session, but in fact is shared across sessions, so data is available to the entire application, not just the current user. This can greatly improve application performance as commonly used data can be held in memory in the application tier.

Implied by the name, Hibernate will go to the first level cache first, and if the entity is not there, it will go to the second level.

Why Hazelcast?

Running a Second Level cache across a cluster of servers adds a layer of complexity when it comes to maintaining concurrency and consistency of data. If one server makes a change to the data, how is that change reflected across your cluster?

Hazelcast® can take care of data distribution for you. Hazelcast can be deployed in distributed or local modes.

In the local mode, when you read from the cache, it will always be local and updates get invalidated). For some use cases, this is a high performance way to deploy Hazelcast as a Second Level cache because entities are guaranteed to be local and in-memory.

In cases where large caches are needed, all of the nodes can pool their memory to create a single, non-replicated cache, with Hazelcast managing concurrency across the cluster. The reads are less performant because data may reside non-locally, but it provides a much larger cache space pooled from al

Spring Cache

The Spring Framework offers a simple caching declaration abstraction through annotation, the abstraction provides two Java annotations: @Cacheable and @CacheEvict which allow methods to trigger cache population or cache eviction.

Hazelcast ships out of the box with support for Spring Cache which allows it to plug in to any Spring application which supports these methods.

Hazelcast maintains a strong connection and commitment to the Spring community through Rod Johnson, who is an investor and board member of Hazelcast.

The Spring Framework provides an abstraction layer for caching providers, which is a first class citizen in Hazelcast. Within the default Hazelcast download /lib directory there is a JAR file hazelcast-spring-.jar which is included in the hazelcast-all..jar By including hazelcast-all.jar or hazelcast-spring.jar, hazelcast can be used as an implementation of the Spring Cache Abstraction layer and can annotate methods as @Cacheable.

As of version 3.1, Spring Framework provides support for adding caching into an existing Spring application. To use Hazelcast as Spring cache provider, you should just define a com.hazelcast.spring.cache.HazelcastCacheManager bean and register it as Spring cache manager.

<cache:annotation-driven cache-manager="cacheManager" />
<hz:hazelcast id="hazelcast">
<bean id="cacheManager" class="com.hazelcast.spring.cache.HazelcastCacheManager">
    <constructor-arg ref="instance"/>

Hazelcast supports other integration points with the Spring Framework, which can be seen in our documentation.


JCache, the Java Caching Standard, officially known as JSR 107 of the Java Community Process, provides access to caching solutions as easy as possible.

Hazelcast IMDG®, the leading open-source in-memory data grid, took the lead to offer the first available native JCache implementation, directly implemented based on the standard itself.

Since simplicity is one of the greatest benefits of Hazelcast IMDG, it made sense to fully integrate JCache. The easiest way is to put the Hazelcast JAR into a JCache-enabled environment (like an application server) and the Hazelcast JCache implementation will be picked up and loaded automatically.

For integration into user applications, Hazelcast IMDG offers a more Hazelcast-like way to access the new JCache caches:

HazelcastInstance hz = Hazelcast.newHazelcastInstance();
ICacheManager cacheManager = hz.getCacheManager();
Cache<Key, Value> cache = cacheManager.getCache(“cache-name”);

The returned javax.cache.Cache instance is ready to be used. Configuration is realized the typical Hazelcast way. Either using the Configuration API or by utilizing the XML configuration mechanism.

There’s also a third way to use JCache, using the official API but that way is mostly for integration into application servers or other environments.

Back to the returned Cache instance. Adding, reading, updating, deleting information from a Cache is as close to java.util.Map as possible.

Adding records works as in the following snippet:

Cache<Integer, String> cache = cacheManager.get(“numbers”);
cache.put(1, “one”);
cache.out(2, “two”);

And as easy as the above adding, are all the other operations:

String one = cache.get(1);
cache.put(2, “maybe-three”);

Obviously the JCache API also supports Hazelcast features like running on Embedded Members or using Hazelcast Clients to connect to a remote client or enterprise additions like security, High-Density Memory Store or others.

Hazelcast IMDG