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

[Brian Stansberry]

Manik Surtani wrote:
> 
> On 20 Mar 2008, at 03:46, Brian Stansberry wrote:
>> Bela Ban wrote:
>>>>> 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
>>> These are simple policies, let's try to find a hard one. For example,
>>> 3. HTTP session replication (Brian): here, we could provide a policy 
>>> which merges the (usually disjoint) data sets. If there are 
>>> conflicts, we could use the number of updates to a session as 
>>> arbiter. Or the time stamp of the last update, or something 
>>> deterministic.
>>
>> The following applies to non-FIELD based sessions.  Once POJO Cache is 
>> involved its a whole different subject.
>>
>> A handler that merged sessions would need to be able to:
>>
>> a) Find out where in the tree the root of interesting data is. That is 
>> the /JSESSION/localhost/webapp Fqn.  A session cache might have 
>> several such points (different webapps) and not all would necessarily 
>> follow the same structure. e.g. you may also have things like 
>> /SFSB/ear=foo,jar=bar,bean=fubar in the same cache if you are caching 
>> SFSBs as well.  With BR this includes the buddy backup subtrees 
>> associated with any "dead" data owners.
>>
>> b) Identify what nodes are the "data owners".  With total replication 
>> this could just be the former coordinator nodes of the subpartitions. 
>> With BR it's every node.
>>
>> c) Provide the names of all the children of the interesting root 
>> across the data owners.
>>
>> d) Provide the data from all the data owners for a given Fqn so the 
>> winner can be selected.
>>
>> e) Compare the contents of nodes to determine a winner. What attribute 
>> map key holds the timestamp; what method on the sfsb holds the timestamp.
>>
>> f) Merge a given subtree once a winner has been picked for a given 
>> Fqn. Get the winner data stored in the right place (which buddy 
>> groups) and the loser data removed.
> 
> So in terms of what you'd need from JBC's merge handler callback:
> 
> 1)  List of each subpartition's members (in order, so you can determine 
> coordinator)
> 2)  Remote (proxy) access to a given cache.  Something like:
> 
>     Cache c = new CacheProxy(currentInstance, addressToProxyTo);
> 
>      so that you could query any caches (coordinators, or all caches in 
> the case of BR) you care about, about their "interesting" roots and 
> children.
> 
> I'm guessing everything you need in c, d and f can be achieved with 
> proxy access described above?
> 

Yes.  Providing a proxy sounds like a good way to do it, in terms of 
what new capability the base cache could add to support this.  A concern 
I had about doing it via RPCs over some channel external to the cache is 
you get into the problem possible membership differences between that 
channel and the cache view.  The cache providing the proxies solves that.

A handler, say for web sessions, would need to solve a-f, with a and e 
being quite use-case specific. Quite possible though the b, c, d, f 
parts using these proxies could be factored out into an abstract 
superclass to allow reuse.

> So I'm now the callback hasn't changed, and still looks like:
> 
> 
>     void handleMerge(Cache currentInstance, List<Address> 
> mergedMembership, List<Address>... subpartitionMemberships);
> 
> NB: CacheProxy does not exist as yet.  It is something we need for 
> Partitioning (JBCACHE-60), so I thought it may make sense here.
> 

Sure.

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

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com