[jbosscache-dev] RE: Mismatch between TreeCache and DistributedState listeners

[Brian Stansberry]

Copying the jbosscache-dev list as this ties in with an ongoing
conversation there re: how nodeModified should work in 2.0.  Jerry, I've
forwarded the thread to you.

My answer really depends on how that discussion turns out, so let's hope
we can resolve it quicky.  If JBC 2.0 is going to start providing the
info you need in the nodeModified callback, #1 makes more sense (since
JBC will do the work for you). Otherwise #2, with the value stored in
the key's map. Downsides to #2 are RAM overhead of adding an extra node
per key, plus different locking semantics.

Jerry Gauthier wrote:
> I've discovered a mismatch between the TreeCache and
> DistributedState listeners.  On the DS side, the modification
> and removal events identify the category, key and value
> applicable to the event.  This worked fine in 4.x with the
> non-TreeCache based implementation.
> 
> With the TreeCache based implementation in 5.0, events are
> handled without any problems on the local node.  However
> events that occur on remote nodes are passed to the DS
> implementation via cache events.  The granularity of cache
> events is restricted to identifying nodes that have been
> modified.  The cache events don't identify the keys or values
> that have been modified or removed.
> 
> Looking closer at DistributedStateImpl, I see that in several
> places the authors assumed that keys would be stored as
> nodes.  But the set method is implemented as
> cache.put(category, key, value) which clearly stores the key in the
> node's map. 
> 
> It seems that there are two possible solutions here, assuming
> we want to have the DS listeners provide the same information as
> before. 
> 
> 1)  When DSImpl receives NodeModify and NodeRemove events, it
> can store the pre and post data maps and then compare to
> determine what's actually changed.
> 
> 2)  We can store all keys as child nodes of the category
> nodes.  Then values can either be children of the keys or
> stored in the key's map.