Posts tagged with: distributed

snowcast – Migration and Failover

When I started snowcast back at end of 2014 I haven’t thought that people will really be interested but most of the times it will work out differently from your imagination. A still fairly small group of interested people showed up and I got a lot of n…

snowcast – Hazelcast Client and the snowcast logo

In December I started a new project called snowcast. Arisen from the need in one of my own private projects I decided to open source this part of the work.
snowcast is an auto-configuration, distributed, scalable ID generator on top of Hazelcast. Since…

snowcast – like christmas in the distributed Hazelcast world

snowcast is an auto-configuration, distributed, scalable ID generator on top of Hazelcast. Since snowcast is not an official Hazelcast project, Hazelcast will not offer any kind of commercial support for it, it is one of my private spare time projects!…

Press Release: OrientDB becomes Distributed using Hazelcast, Leading Open Source In-Memory Data Grid

OrientDB becomes Distributed using Hazelcast, Leading Open Source In-Memory Data Grid Elastic Distributed scalability added to OrientDB, a Graph Database that support hybrid Document Database features Palo Alto, CA – Hazelcast ( and Orient Technologies ( today announced that OrientDB has gained a multi-master replication feature powered by Hazelcast. Clustering multiple server nodes is the […]

Writing a Hazelcast / CastMapR MapReduce Task in Java

 Hazelcast is a distributed In-Memory-Datagrid written in Java. In addition to the internal features like EntryProcessors and queries you can write MapReduce tasks using the CastMapR projects which adds MapReduce capabilities on top of Hazelcast 3…

Hazelcast and MongoDB

Hazelcast and MongoDB

In this article, I will implement a sample (getting-started) project which uses MongoDB as persistence layer for Hazelcast distributed cache.

Hazelcast has a flexible persistence layer, you should just implement an Interface (MapStore) to store your memory grid into your preferred database. By 2.1 version Hazelcast supports MongoDB persistence in a smoother way using Spring-MongoDB data library. Let’s implement a simple project step-by-step to illustrate this feature. Our project will have a single model class and we will see it will persisted to MongoDB when we put it to Hazelcast distributed map.
1- Project Set-Up
I will use Maven. Here the dependencies:
The dependencies are libraries for projects Spring, Spring-MongoDB, 
Hazelcast makes use of Spring Data project, connecting and mapping objects to MongoDB.

2- MongoDB Set-Up
Install and run mongodb in your local machine. One of the things makes mongodb attractive, its quick-start is really quick. 
You can follow this guide:
3- Model
A simple POJO to store basic info about users. Only thing you should care, it should be Serializable.
4- Configuration
As we use Spring, all configuration is bundled in Spring configuration xml. I named the file as beans.xml
5- Run and Test
Now we can test Mongo-Hazelcast integration. What we will do is to get the user map from spring context and put a new User object into map. We do not add any code related to Mongo or database layer, the object should be saved to MongoDB automatically. Also there is no Hazelcast code in this class. It seems that it just puts an object to a map. But in fact the object is put to distributed data grid, also persisted to MongoDB. The code is so clean thanks to Spring and the Hazelcast’s standart Map implementation.
Here the main class for that:
And let’s see if it is in Mongo:

MongoDB shell version: 2.0.2
connecting to: test
> db.user.find()
{ “_id” : “id-134”, “_class” : “com.hazelmongo.User”, “name” : “Enes”, “age” : 29 }
As you see, Mongo generates two fields other than the ones defined in POJO. _id field is assigned from the key which you used putting to the map. And _class is used to map record the corresponding Java Object.

This sample illustrates the default usage of MongoDB-Hazelcast. You can override default behaviour and object mapping (annotating the POJO) thanks to Spring Data project. Have a look at here for further details.