Open Gitter Chat

Caching

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">
    ...
</hz:hazelcast>
<bean id="cacheManager" class="com.hazelcast.spring.cache.HazelcastCacheManager">
    <constructor-arg ref="instance"/>
</bean>

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

Hazelcast.org

Main Menu