Re: [jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE
> 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