Bela Ban, the project lead for JGroups and JBossCache, presented an elegant and straightforward overview of how to replicate data across a cluster of application server instances, a task that is surprisingly non-trivial. At first glance, replicating a few POJOs across a few instances does not appear overly complex. However, as soon as the real world requirements become clear, most cache implementations force development teams to choose between implementation hurdles. The first hurdle is usually related to the amount of data and the number of nodes that require the data. As large systems scale, vanilla schemes for replication usually fall short because various requirements mandate radically different approaches. Consider a one megabyte object that must be maintained across twenty server instances. To send the entire object to every server for each update might work in a LAN but will most likely fail in a WAN where latencies are much greater. This point underscores the need for bullet-proof caching solutions as we continue to satisfy the demands placed on us by ever increasing complexity and user loads. The first tactic JCache employs to address scaling is the old trick of divide and conquer. The cache is divided into nodes represented by a fully qualified name (FQN). A FQN looks like a normal URL expression appended with an object name and slash delimiters. Another strength of JCache is that it can be configured to wrap cache updates within a transaction. This provides fine grained control over when an object should be pushed to other nodes. The ability to declare that cache objects in local only also prevents unwanted network traffic without additional logic with the application. Object locking is always an important consideration when replicating data. The API supports optimistic and pessimistic locking and Bela correctly points out that the design the cache should reflect this nature of the objects locking requirements. Minimize the size of the cache that requires pessimistic locking to ensure higher throughput. Next, the concept of Buddy Replication (BR) and a multiple-tier cache loading is also quite interesting. A multi-tier cluster facilitates the definition the most vital data and memory based caching policies. Subsequent nodes can be replicated to a remote cache and persisted to minimize the memory requirements. A get function traverses the configured cache loaders to retrieve the object from process based cache and only when required, the object will be retrieved from the persistence layer. This approach delivers the data from memory when possible which increases overall application performance. All of these presentations for TSSJS-Europe are now online.

:-)

Seems that Coherence and JBoss Cache cover the same space. What, if any, compeling advantages does JBoss Cache have over Coherence (except price) ? And vice versa? How about WebSphere Object Grid?

I've been using coherence for a while and it's in a different league all together compared to jboss cache. The last time I used JBoss cache - it didn't have a partitioned caching scheme (near cache is great) - write-back cache support, and it required a large amount of jar dependencies (some from the Jboss server). Coherence is a joy to work with, well documented, and just works. Last time I used it was to augment ColdFusion MX's Client Management scheme which is just plain awful and performs over five-six sql queries during every page hit (our database will thank us for aleviating it from non-transactional work). It was fairly easy to write a facade JDBC driver that used a coherence near-cache intead.

How about comparison with JavaSpaces based GigaSpaces?

It's a shame he didn't cover the new invalidation modes that JBoss cache supports. It can greatly reduce network traffic and less time spent in serialization/deserialization of object data and also makes some scenarios a lot simpler (such as reduced need for object locking).

I've heard Bela speak before-- he knows what he's talking about. If you've got clustering issues, Bela's probably got a good answer for your problem. Rick P.S. Has anyone else noticed the stellar lineup JBoss has been gathering? Some are flashy (i.e. Gavin), some less flashy, but there's depth across the whole lineup...

Actually I've run into performance issues with clustering and was more talking about helping others than me :) I tried using the invalidation mode in JBoss cache since it was initially commited to CVS until the release, but it is still a bit young, and the biggest problem is that it isn't yet compatible with Hibernate. In the meantime I have implemented my own invalidation cluster-cache on top of JGroups (I love JGroups, hard to configure but extremely efficient when it works !). My wish for JGroups while I'm on the subject : better documentation, especially of all the protocols (trying to understand what they do from the javadoc is not exactly easy), as well as some monitoring tools would be great. Oh and at last I'd help, but I'm really overloaded :)

[...] invalidation mode in JBoss cache since it was initially commited to CVS until the release, but it is still a bit young, and the biggest problem is that it isn't yet compatible with Hibernate.

I think the recommended combo for invalidation and Hibernate/JBossCache is Hibernate 3.2 and JBossCache 1.4. Actually, 3.2/1.4 is also the recommended solution for the locking issues Hibernate/JBossCache had... Sorry for not covering invalidation, should have added another slide there... :-)

In the meantime I have implemented my own invalidation cluster-cache on top of JGroups (I love JGroups, hard to configure but extremely efficient when it works !).

My wish for JGroups while I'm on the subject : better documentation, especially of all the protocols (trying to understand what they do from the javadoc is not exactly easy), as well as some monitoring tools would be great.

Oh and at last I'd help, but I'm really overloaded :)

I'm working on the documentation (docbook): http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html. The wiki (http://www.jboss.org/wiki/Wiki.jsp?page=JGroups) also describes the various protocols and their parameters. Thanks for the kudos ! Bela