Re: [jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE
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(a)jboss.org