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

[Brian Stansberry]

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.


I divide that list into 2 groups: stuff I'd like the cache to do 
internally, with some API exposed: that's b, c, d, f.  And stuff an 
application specific handler (i.e. AS code) should do, perhaps building 
on some abstract helper class provided by JBC: that's a and e.  I don't 
think there's much point trying to program "generic" versions of a and e 
into the JBC code base.

In Neuchatel we also discussed that AS code might be responsible for 
everything; i.e. it would use RPCs over a separate channel to coordinate 
calls on the various caches to accomplish b, c, d and f.

> 4. Untion of all substates. Again, if the user provides an ID of some 
> sort, we might be able to take advantage of that.
> 
>> 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).
> 
> Yes, but as soon as you start looking into 3 and 4, this interface might 
> change. My point is that an interface is a public API, once you've 
> provided it, it gets hard to change it.
> 

I agree on the "hard to change" bit. But, when I think about the things 
I'd like from the cache above (b, c, d, f) they are not part of the 
interface of the MergeHandler.  They are part of the interface of the 
cache -- things that need adding to allow a particular MergeHandler impl 
to do its job. The MergeHandler itself just needs a notification telling 
it a merge has happened.

> I don't think we have thought hard enough about all use cases we might 
> implement, or at least consider for the design of the interface. Maybe 
> we need to brainstorm about this at our next clustering conf call ?
> 

Ok.

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