No, JBoss Cache has no way to merge application state since the cache has no knowledge of the context of it's contents and how this should be merged.

There is an open JIRA about this, with some potential solutions (evict all in-memory state when the network heals and assume that the state can be retrieved from a cache loader/shared database, or provide a callback into user code which could handle merging based on knowledge of data in the cache, etc).

http://jira.jboss.org/jira/browse/JBCACHE-471


On 7 Nov 2007, at 18:13, Bill Doster wrote:

I'm hoping that JBoss Cache can recover cache consistency following a
transient network outage.  From my readings of both Cache and JGroups,
I've ended up thinking that it's JGroups that notices begin-and-end
of network partitions and that JGroups then notifies dependent classes
so that they know that they need to deal with the potential merging of
any higher-level state changes in each sub-cluster during the network partition.

This seems consistent with a recent response from Bela Ban (2007.0914):

http://sourceforge.net/mailarchive/message.php?msg_id=46EA2BA0.9090508%40yahoo.com
 
But from my understanding of JBoss Cache (the dependent class I'm considering) via:

"JBoss Cache TreeCache: A Structured, Replicated, Transactional Cache"
(http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1.SP4/TreeCache/en/html_single/index.html)

I can't identify anything as directly addressing JBoss Cache's "application-data" healing from a network partition...

Here's a particular test scenario that would need to handle the situation I'm thinking of:

JBoss Cache ClusterName="A-B" with two members ("A" and "B") is started.

"A" and "B" both view "A" as "coordinator".  

To keep things simple, let's have only a single region.

No Cache Loaders are used -- thus all Cache state exists only in-memory (no back-end data store).

Time passes peacefully and "A-B" builds up some amount of Cache state, all of it consistent across A and B.

Then, a network partition occurs (perhaps a backbone router is powered down for 10-15 minutes to add an additional card).

After some amount of time, both A and B finally end-up marking each other "dead" and themselves
as JGroup coordinator for their sub-cluster.

During this partition, both A and B can continue to accept updates to their Cache state, right?  
And this would result in the now-independent Caches becoming distinct from each other.

So, once the result of the network partition is resolved, JGroups will realize this and notify JBoss Cache
via a ViewChange.

My question is:

 does JBoss Cache itself somehow merge the during-partition state changes together?

Since neither member was itself down and both could potentially have partition-related state changes,
causing either to simply dump their in-memory state and ask for a full state-transfer will result in a
loss of information.

_______________________________________________
jbosscache-users mailing list
jbosscache-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-users

--
Manik Surtani
Lead, JBoss Cache