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

[Bela Ban]

>> 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.

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 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 ?



-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat