[jbosscache-dev] RE: Mismatch between TreeCache and DistributedState listeners
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.