How do you start the nodes and what kind of clustering (UDP TCP Multicast) you use?
Normally if the network connection becomes reavailable the nodes should connect and heal the cluster.
We are thinking to use TCP unicast with 2 NODES.
The real problem is the algorithm to decide how to merge the state of the cluster after the nodes have been divided for a while ( and 2 different user have accessed and modified the same business data). It is possible to implement some sort of algorithm or is it symply out of the scope of jboss clustering?
As Wolf says, the nodes should merge back in the cluster when the network becomes available. If the partition name and UDP address is the same, there should be no problem.
I see your point with merging though -- briefly, what would your merge algorithm do?
Hm, I guess you could compare timestamps you store yourself in HTTP sessions and merge them together keeping the newer, evicting the older one.
However, I am under impression this has not been implemented https://issues.jboss.org/browse/JBCACHE-772 as split brain scenario is not easy to handle. BTW these reconnects are not handled by JGroups (and cant really be), it should be handled by JBoss Cache.
In our scenario is not a simple matter of HTTP session timestamps, but we have data acquired from one independent sources (for every node) and we have to look at data collected to understand what is the "RIGHT" node.
can you link me some JBoss Cache resources about this ?
Than you very much. At the moment I googled around a lot (for a lot of months) but no applications serves seems to resolve this need.
1 of 1 people found this helpful
This is a difficult problem to solve. If you have a DB, to which both nodes have access, you could simply clear the cache on a MergeView, and have it warm up gradually by using a DB CacheLoader.
Note that, similar to Amazon's Dynamo, Infinispan will (next version?) carry versions with the data. When there are conflicting updates to the same data, the application developer will be asked to resolve the conflict. If this might be of interest to you, I suggest post to the Infinispan forums or dev list.
DB is uniqe for each node, not shared .
I will check for Infinispan :-)
Here is a link to what Bela is talking about -- the eventual consistency in Infinispan: https://issues.jboss.org/browse/ISPN-999 Its on plan for the next major version of Infinispan. One of the main improvements is partition tolerance which is what you seem to be after Version-aware entries could make it to 5.2 release, see https://issues.jboss.org/browse/ISPN-1116