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

[Bela Ban]

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);
> }
>
> 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 ?
- The notion of winning and losing partition implies that we're using a 
winning-lossing partition merge, which may not be applicable.

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...

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat