[jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE

[Manik Surtani]

On 19 Mar 2008, at 10:00, Bela Ban wrote:
>
>
> Vladimir Blagojevic wrote:
>> Looking through JGroups merge code; there is a possibility of n-way  
>> merge so it is not always the case that we have a two way merge as  
>> suggested interface indicates. How about something like:
>>
>> public interface MergeHandler
>> {
>>   void handleMerge(Cache currentInstance, List<Address>  
>> preMergeView, List<Address> postMergeView);
>> }

How about:

	void handleMerge(Cache currentInstance, List<Address>  
mergedMembership, List<Address>... subPartitionMemberships)

where subPartitionMemberships will list each of the n sub groups being  
merged, the "winning" one being first?

>>
>>
>> Manik Surtani wrote:
>>> This was on 2.2.0's task list:
>>>
>>>    http://jira.jboss.com/jira/browse/JBCACHE-471
>>>
>>> The last time we spoke about this was in Neuchatel, and we decided  
>>> we'd expose an interface, a MergeHandler, that people could  
>>> implement.  We'd also provide a few standard implementations, like  
>>> EvictEntireClusterStateHandler and FatalStopMergeHandler?  I think  
>>> a SingleWinnerHandler  and DisjointedSubtreeMergeHandler can come  
>>> later, as they would both involve a proxying mechanism to talk to  
>>> remote caches being in place - something which will be developed  
>>> as a part of Partitioning [1].
>>>
>>> We didn't discuss the design of this interface - how about a  
>>> single callback with:
>>>
>>> public interface MergeHandler
>>> {
>>>    void handleMerge(Cache currentInstance, List<Address>  
>>> winningSubPartition, List<Address> losingSubPartition);
>>> }
>
> - Maybe we should have the ability to provide additional information  
> for each partition, maybe even for each node, provided by the app ?

How would this happen?  It would require a few levels of callback then  
- one to gather this extra info per instance, and another to deliver  
the handleMerge callback, with the info from all instances?

> - The notion of winning and losing partition implies that we're  
> using a winning-lossing partition merge, which may not be applicable.

True, plus as Vladimir suggested, there could be more than 2 subsets  
of the cluster.

> I suggest you come up with a number of scenarios you'd like to cover  
> in JBC and then we see what information is needed. Maybe  
> implementing this will make the interface clearer...

As far as JBC is concerned, I think we can only handle 2 scenarios  
effectively.

1.  EvictEntireClusterStateHandler
Each instance evicts it's local tree when it gets this.  A variation  
of this could do a remove instead of an evict (to clear local cache  
loader state as well).  Useful if the data exists elsewhere - e.g.,  
when used with Hibernate.

2.  FatalStopMergeHandler
Logs a fatal error and shuts down the cache when a merge is detected.

Anything else involves heuristics of how data is organised in the  
cache, which may result in corrupt state.  Maybe it is better to  
describe these approaches on a wiki and let people implement these  
handlers themselves.

Either way though, this discussion is to design the handler interface  
- as far as solutions 1 and 2 above are concerned, all you need is a  
reference to the current cache instance (to (1) evict all state or (2)  
stop the cache).  I just thought adding the views into the callback  
would help with users - armed with knowledge of their data  
organisation in the cache - achieve a more flexible approach to  
handling a merge.

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org