Open Gitter Chat


Elastic Memcached

Hazelcast has been used in production as either an “alternative” to Memcached or as a plug-in enhancement.

If you’re already using Memcached, you can write a hazelcast cluster by simply using our Memcached client using any language. No additional configuration is required. Here is an example: Let’s say your cluster’s members are:

Members [5] {
Member []
Member []
Member []
Member []
Member []

And you have a PHP application that uses PHP Memcache client to cache things in Hazelcast. All you need to do is have your PHP memcache client connect to one of these members. It doesn’t matter which member the client connects to because Hazelcast cluster looks as one giant machine (Single System Image). PHP client code sample:

$memcache->connect(’′, 5701) or die (“Could not connect”);
$get_result = $memcache->get(‘key1′); //retrieve your data
var_dump($get_result); //show it

Notice that memcache client is connecting to and using port5701. Java client code sample with SpyMemcached client:

MemcachedClient client = new MemcachedClient(AddrUtil.getAddresses(“″));
client.set(“key1″, 3600, “value1″);

An entry written with a memcache client can be read by another memcache client written in another language.

You may also elect to use Hazelcast instead of Memcached, some advantages would include:

  • Elastic Clustering: you can add 5 more nodes without touching your clients at all!
  • Embeddable with your Application Tier. You don’t have to run separate cache servers and remotely connect to it.
  • Flexible for developers to write smarter apps by using listeners, locks etc.
  • Featureful more than acache; it has queue, topic, executor service..
  • All in-one. easier to maintain.
  • Simple. Normal collections classes API and solid default configuration.
  • Backups: Memcached has only one copy of each object at one node.
  • Easy Deploy: Java only product in one single jar. Simply drop it in. No installation and so on. Its for a Java-only project we need this.

Anyhow, we dont want you to get the wrong impression, we think Memcached is a good product. We feel that it’s possible for you to extend your use of Memcached and possibly go further with Hazelcast, but ideally you wouldnt take our word for it, you would just try it and see.

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 here:

16.1. Configuration
16.2. Spring Managed Context
16.3. Spring Cache
16.4. Hibernate 2nd Level Cache Config
16.5. Spring Data – JPA
16.6. Spring Data – MongoDB

Main Menu