Re: [jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE
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(a)jboss.org
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev