JBoss Cache 1.4 Released; Adds Buddy Replication

Posted by Floyd Marinescu on Jul 17, 2006

Sections

Development,

Architecture & Design

Topics

Java ,

Clustering & Caching

Tags

JBoss Cache

JBoss has released JBoss Cache 1.4 final, their distributed caching product which also includes PojoCache (formerly TreeCacheAOP).  The release adds Buddy Replication and Data Gravitation features and also optimizes their RPC marshalling algorithm resulting in 20-50% improved performance and throughpout. JBoss Cache is the technology behind JBoss Application Server's HTTP and EJB session replication.  InfoQ spoke to project leads Ben Wang and Manik Surtani to get more information.

Previously, JBoss Cache multicasted cache changes across all nodes in the cluster, which would make it inefficient for cases where cache data is partitioned (such as when you have session affinity). With the new buddy replication feature, instead each server instance picks one or more 'buddies' in the cluster, and only replicates to these specific buddies.  When asked about why one needs distributed caching if you have a cluster with session affinity, responded:

when you have a local cache+session affinity, you'd still want some replication for failover/high availability, one example being HTTP sessions.  This is where buddy replication comes in, improving efficiency so you don't end up replicating your entire state across the cluster - just to nominated backup nodes. 

Buddy Replication is an important feature for the project to gain in order for it to become suitable for larger deployments where inter-node communications overhead must be minimized. Other commercial solutions such as Tangosol or IBM's ObjectGrid have had this for some time. Terracotta doesn't use/need a buddy system since data is replicated to a central cache server.

JBoss Cache uses JGroups,  a group communication toolkit, to manage network-level communications between instances. Manik Surtani told InfoQ:

we've used this to build an RPC layer, wich we then use to replicate data across a cluster.  Using JGroups, we get a number of things for free, including group membership and organisation, guaranteed message delivery, and network stack tuning (switching between TCP and UDP, tunnelling through firewalls if necessary, etc).

PojoCache is a componeont of JBoss Cache which allows you to avoid interacting with the cache with a Map interface after update operations; instead, an object instance is added to the Cache with one initial PUT, and field-level changes to the object are intercepted transparently with aspects and then distributed across the cluster.

Ben Wang positioned JBoss Cache as a competitor to Tangosol (from the perspective of both being distributed Maps) and PojoCache as as more like Terracotta (from the AOP-driven, API-less perspective).

1. Back to top

   GigaSpaces cache

   by Guy Korland

   GigaSpaces provides similar capabilities with a richer API based on JavaSpaces API (GigaSpaces also provides a simple Map API). But can also provide a full partitioned solution even if the session affinity isn't saved.
   
   Guy korland
   GigaSpaces: Write Once Scale Anywhere

   Reply

2. Back to top

   Re: GigaSpaces cache

   by Brian Ehmann

   It would be nice if Infoq could charge for inserting advertisements in comments?
   
   Brian E

   Reply

3. Back to top

   Clarifications

   by Cameron Purdy

   Buddy Replication is an important feature for the project to gain in order for it to become suitable for larger deployments where inter-node communications overhead must be minimized. Other commercial solutions such as Tangosol [..] have had this for some time.

   
   
   Tangosol Coherence does not use buddy replication. With "n" servers, it dynamically organizes a server mesh (partitioned as n x n, and dynamically load-balanced as n increases) that has a configurable depth (e.g. 3 for n plus 2 failover scenarios) that can be specified on a data set by data set basis.
   
   To compare:
   
   
4. - With a buddy system and 100 servers, the death of a server will double the load on its buddy.


5. - With a partitioned n x n mesh, the death of a server will increase the load on other servers by roughly 1 percent.


This technologoy was introduced by Tangosol in June of 2002, and serves as the fundamental basis for much of the state-of-the-art in data grids today.

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid