HazelCast - clustered transactional cache

In my recent quest for a clustered transactional cache I came across Hazelcast.

Hazelcast is a distribute cache implementaion written in java, it has a distributed implementation of java.util for Map, List, Set.

it also has some neat distributed Queue, Topic, Executer implementations.

since the header of this post consists on distributed transactional cache I will not talk about those neat features (they are not transactional).

 

the idea of Hazecast is to be easy to work with, hide the distribution details and support a large scale.

following the documentation, hazelcast has only one jar, consiting with it's small footprint and ease of use.

in order to start working with the cache, you will need to create a hazelcase.xml configuration file or work with the default one that is attached to the hazelcast jar.

I decided I'm going to make things the hard way and try and configure it by myself. I'm happy to say that it was a good expirience. there are a few way of loading you configuration file, through classpath, file system, memory or url loaders.

I worked with the file system loader as follows -

Config config = new FileSystemXmlConfig(new File("C:/playground/cache/hazelcast/target/classes/hazelcast.xml"));
HazelcastInstance instance = Hazelcast.newHazelcastInstance(config);

 

and that's it.

the tests were done on a single machine.

I ran a producer and listener(same configuration), and instatly I had a cluster that replicates each action.

 

now for the real question, how does it work with transactions?

 

Hazelcast has it's own transaction support, with the same notion of begin, commit, and rollback.

according to the documentation it can be adjusted to work with user transactions. I have't tried the J2EE integration since the basic hazelcast transaction support was suitable for my needs.

 

after adding the transaction support my producer looked as follows -

package hazelcast.demo;

import java.io.FileNotFoundException;

import com.hazelcast.core.Transaction;

 
public class HCProducer extends HCBasicRunnable {
 
	public HCProducer() throws FileNotFoundException
	{
		super();
	}

	@Override
	public void run()
	{
		int i = 0;
		String value = "val-";
	
		Transaction txn = instance.getTransaction();
		txn.begin();
		
		while (true)
		{
	        map.put(Integer.toString(++i), value + i);
	        System.out.println("put in map " + i);
	        
			if (i % 5 == 0)
			{
				System.out.println("commit transaction");
				txn.commit();
				
				System.out.println("start new transaction");
				txn = instance.getTransaction();
				txn.begin();
			}
	        
	        try
			{
				Thread.sleep(1500);
			}
			catch (InterruptedException e)
			{
				e.printStackTrace();
			}
		}
	}

    public static void main(String[] args) throws FileNotFoundException {
    	(new Thread(new HCProducer())).start();
    }
} 



and the listener as follows -

 

package hazelcast.demo;

import java.io.FileNotFoundException;
import java.util.HashMap;
import java.util.Set;

public class HCListener extends HCBasicRunnable
{

	public HCListener() throws FileNotFoundException
	{
		super();
	}

	@Override
	public void run()
	{
		while (true)
		{
	            try
		    {
		       Thread.sleep(5000);
		    }
		    catch (InterruptedException e)
		    {
		       e.printStackTrace();
		    }
                }

	}

    public static void main(String[] args) throws FileNotFoundException {
    	(new Thread(new HCListener())).start();
    }

}

 

and that was it. now I had a full blown transctional cluster.

now there's always a catch, right?

when running some load test I found out that calling "map.get" consums too much time, about 0.001 sec per call. since my application requires lots of calls this is not something I could ignore.

according to hazecast team this is a known issue and an expected behaviour since hazelcast was built to work as a distributed cache, and not a replication. I did some digging and found this amuzing but resonse on the hazelcast group

still, I needed better performance. apparantly those guys know what they're doing, and for that they have the "Near Cache" feature.

I updated my configuration and now I had a full blown transactional distributed cache with high performance on read actions.

 

I must say that after expienecing with the latest EHCache versions, I was happy to find an open source that it performs to its documentation...

I think that hazelcast is excelent in what it does. it's very easy to configure, use and deploy.

it lacks in documentation, especially on the configuration part (couldn't find how to configure a topic, still managed to anyhow).

since it's still new, it also lacks in web buzz. I couldn't find too much articles and "howto" tutrials. but I'm guessing that will change in the near future.

 

to sum things up, I can't say that hazelcast will cause EHcache or JbossCache to "bite the dust", but I'm willing to bet that it will take a nice bite in the distributed cache market.

 

 

 

 

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com