[jboss-user] [JBoss Cache] Document updated/added: "JBossCacheBuddyReplication"
User development,
The document "JBossCacheBuddyReplication", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10255#cf
Document:
--------------------------------------------------------------
h2. Buddy Replication
Buddy replication - the ability to replicate your HTTP or SFSB session data to specific
servers in a cluster and not to everyone - is a feature that is WIP in JBossCache at the
moment, and will probably not be ready for production use till the summer of 2006. That
said, the goals of buddy replication could still be achieved with the new features in
JBossCache 1.3 - the underpinning technology used by JBoss session replication.
Let us analyse the goals of buddy replication. Buddy replication is used:
1. to achieve failover by ensuring that collective state of a cluster is maintained even
if some servers in a cluster go down.
2. to minimise network traffic that is a result of full replication of state to all
servers in a cluster.
3. to minimise memory usage which is a result of each server maintaining not only its own
state but the state of _every_ server in the cluster.
Until we have a production-ready buddy replication implementation, there are some
interesting new features in the upcoming JBossCache 1.3 that can be used to achieve
similar results.
h3. JBossCache 1.3.0 (due for release in March 2006)
Some new features in JBossCache 1.3.0 that we could use:
* Chaining Cache Loader. This feature allows you to configure more than one cache
loader.
* ClusterCacheLoader. This cache loader queries in-memory state of other caches in the
cluster, behaving as a cache loader.
* New cache mode - INVALIDATION rather than REPLICATION - so that when a node is updated,
rather than replicating data, other caches receive an invalidation message to evict the
node in memory. This way we can notify other caches in a cluster of an update without
needing to replicate the changed objects.
h2. Using these features to achieve the effects of Buddy Replication
*1. To achieve durability of persistent data:*
* A chaining cache loader should be configured with a ClusteredCacheLoader and a
JDBCCacheLoader.
** Use the ClusteredCacheLoader to quickly retrieve data from other caches in the
cluster.
*** Should be tuned with sensible timeouts.
** Use the JDBCCacheLoader as the 'true' representation of all state in the
system.
*** Should be shared so all servers use the same JDBCCacheLoader
*2. To minimise network traffic:*
* If a cache cluster were configured with invalidation rather than replication, we have
effectively minimised network load.
*3. To minimise memory usage on cluster nodes:*
* Since data is not replicated to all servers in the cluster, all servers don't
maintain all session data in the cluster.
* The caches should be tuned with a sensible eviction policy
h3. This does not mean we're NOT doing Buddy Replication!
Alternatives are always good, but just because we have one does not mean we will not be
adding production-grade buddy replication to JBossCache in the very near future. Watch
this space, but in the meanwhile, if you run a cluster of a large number of servers and
want to achieve some of the goals of buddy replication, consider tuning JBossCache 1.3.0
as described above.
Buddy replication is targeted for release in JBoss Cache 1.4.0 "Jalapeno", by
the end of April 2006. See JBossCacheBuddyReplicationDesign for an idea of what to
expect.
h3. Sample configuration files
See
http://anoncvs.forge.jboss.com/viewrep/JBoss/JBossCache/etc/META-INF/opti...
in the /etc/META-INF directory of the JBossCache CVS tree.
--------------------------------------------------------------