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

[Vladimir Blagojevic]

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);
> }
>
> Can we see any other information being needed?
>
> [1] http://jira.jboss.org/jira/browse/JBCACHE-60
>
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
>
>
>
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev