Cool. One other small thing: for completeness the MapModifications
struct should probably also have a "public Map unmodifiedEntries" field.
Manik Surtani wrote:
Ok, sounds cool, will add this to the JIRA task.
> How about a variation on Ben's idea of providing an enum to specify
> the type of change? Sample API follows.
>
> /**
> * Called before and after a {@link Node} is modified. Data passed
> in the
> * <code>modData</code> param can be used to determine what was
> modified.
> * <p/>
> * When called with <code>pre == true</code>,
<code>modData</code>
> is the
> * initial state of the {@link Node} before modification.
> * <p/>
> * When called with <code>pre == false</code>, the contents of
> <code>modData</code>
> * depend on the value of <code>modTtype</code>:
> * <ul>
> * <li><b>PUT_KEY_VALUE</b>: Map contains the single key/value
pair
> that was added.</li>
> * <li><b>REMOVE_KEY_VALUE</b>: Map contains the single key/value
> pair that was removed.</li>
> * <li><b>PUT_MAP</b>: Map contains the new state of the {@link
> Node} following modification.
> * This map includes modified key/value pairs as well as any that
> were not affected.</li>
> * </ul>
> * <p/>
> * Implementations interested in seeing the difference in the node
> data in the PUT_MAP case
> * can cache the <code>modData</code> map passed when <code>pre ==
> true</code>, and then
> * when the <code>pre == false</code> callback is received, pass the
> cached map and the new
> * <code>modData</code> to {@link
> org.jboss.cache.util.Util.diffNodeData(Map pre, Map post)}. *
> * @param fqn Fqn of the node being modified
> * @param pre <code>true</code> if the modification is about to
> be applied,
> * <code>false</code> if it has already been applied
> * @param isLocal <code>true</code> if the modification originated
> locally,
> * <code>false</code> if it was replicated from
> another node
> * @param modType PUT_KEY_VALUE, REMOVE_KEY_VALUE or PUT_MAP
> * @param modData Unmodifiable {@link Map}; will not be
> <code>null</code>. See
> * description above.
> */
> public void nodeModified(Fqn fqn, boolean pre, boolean isLocal,
> ModificationType modType, Map modData);
>
> public class Util {
>
> public static MapModifications diffNodeData(Map pre, Map post) {
> // do the diff here }
>
> public static class MapModifications {
> public Map addedEntries;
> public Map removedEntries;
> public Map modifiedEntries;
> }
> }
>
>
> Advantage here is JBC goes to little effort to support this, so
> overhead is low if the listener isn't interested. CacheListener impls
> that are interested in modifications, but where the app never calls
> put(Fqn, Map)
> also have very little overhead. I believe Jerry's DistributedState
> is such a case. The big overhead of doing the diff is only incurred
> by CacheListener impls that care, and we provide much of the code to
> do it for them.
>
> - Brian
>
> Jerry Gauthier wrote:
>> This issue is relevant for DistributedState in AS 5.0 where the
>> implementation was rewritten to use TreeCache for the underlying
>> replicated store. There's currently a mismatch between the events
>> published by DistributedState and those offered by TreeCache.
>> Specifically, DistributedState identifies the data key and new value
>> for modified categories (which are TreeCache nodes); it also
>> identifies keys that are removed. Currently it's not possible to
>> obtain this information from TreeCache unless the subscriber
>> responds to the "pre" and "post" modification events by
retrieving
>> the modified node's Map before/after and then performing a diff
>> operation.
>>
>> I've looked at the new CacheListener interface and it looks like it
>> helps a little since it provides the Map as part of the event. But
>> as Ben pointed out, it's still necessary for the subscriber to diff
>> the maps to determine what was changed. So this doesn't appear to
>> help significantly for DistributedState as the hard part is
>> performing the diff, not retrieving the map.
>>
>> Jerry
>>
>>
>>>>> "Brian Stansberry" <brian.stansberry(a)jboss.com>
10/30/06 11:33 AM
>>>>>
>> How common is the use case where the listener wants to know the
>> differences? I'd be concerned about the overhead of creating
>> objects to encapsulate the diff every time there is a change --
>> just so those objects can be passed to a CacheListener that ignores
>> the data.
>>
>> OTOH, even if the current approach of just handing out the new data
>> map is used, that should at least be a Collections.unmodifiableMap
>> wrapping the internal data structure, so there's overhead there as
>> well. Probably
>> a wash, except in the put(Fqn, Map) case, where doing the diff is
>> more tedious.
>>
>> I guess I have no strong opinion on this...
>>
>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>> Hmm, which approach do people prefer?
>>>
>>> And how would a nodeModified event from an operation like put(Fqn,
>>> Map) be represented, since it may represent both data added as well
>>> as data modified? I don't think this should result in multiple
>>> callbacks.
>>>
>>> Cheers,
>>>
>>>
>>>> Yes, I did realize that. But implementation wise, it should be
>>>> straightforward since Cache knows exactly the identifier, right?
>>>> We just need to add an "identifier" enum in the nodeModified
>>>> callback. Downside is one more parameter but upside is faster
>>>> processing such that we don't hog the calling thread.
>>>>
>>>> -----Original Message-----
>>>> From: Manik Surtani [mailto:msurtani@redhat.com]
>>>> Sent: Monday, October 30, 2006 11:15 PM
>>>> To: Ben Wang
>>>> Cc: jbosscache-dev(a)lists.jboss.org
>>>> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data
>>>> in callbacks
>>>>
>>>> Well, nodeModified covers 3 scenarios:
>>>>
>>>> 1) Data added to map
>>>> 2) Data removed from map
>>>> 3) Existing map data changed
>>>>
>>>> if we just passed in deltas, we'd also need to pass in keys to
>>>> describe the operation. I.e., a nodeVisited event could pass in a
>>>> key-value pair, but we'd also need to pass in an identifier to
>>>> describe the modification. Which makes it pretty tedious.
>> This is
>>>> why I opted for just passing a snapshot of the state of data
>>>> before and after the mod.
>>>>
>>>>
>>>> --
>>>> Manik Surtani
>>>>
>>>> Lead, JBoss Cache
>>>> JBoss, a division of Red Hat
>>>>
>>>> Email: msurtani(a)redhat.com
>>>> Telephone: +44 7786 702 706
>>>> MSN: manik(a)surtani.org
>>>> Yahoo/AIM/Skype: maniksurtani
>>>>
>>>>
>>>>
>>>> On 29 Oct 2006, at 16:20, Ben Wang wrote:
>>>>
>>>>> Yes, are are right. Silly me, I was looking at the pre only.
>>>>>
>>>>> Still, my question is that will it make more sense during post-
>>>>> nodeModified notification to deliver only the data modified (not
>>>>> the new data map). If I am only interested what portion of my
>>>>> data has been modified (and I belive this is a quite common use
>>>>> case), then I would need to keep an old data map and diff it
>>>>> with the new data map. Doable but it would be a performance
>>>>> killer for sure.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Ben
>>>>>
>>>>> -----Original Message-----
>>>>> From: Manik Surtani [mailto:msurtani@redhat.com]
>>>>> Sent: Friday, October 27, 2006 11:14 PM
>>>>> To: Ben Wang
>>>>> Cc: jbosscache-dev(a)lists.jboss.org
>>>>> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data
>>>>> in callbacks
>>>>>
>>>>> Is this when pre is true or false?
>>>>>
>>>>> If pre is true, the data will be the old data. If pre is false,
>>>>> it will be the new data. -- Manik Surtani
>>>>>
>>>>> Lead, JBoss Cache
>>>>> JBoss, a division of Red Hat
>>>>>
>>>>> Email: msurtani(a)redhat.com
>>>>> Telephone: +44 7786 702 706
>>>>> MSN: manik(a)surtani.org
>>>>> Yahoo/AIM/Skype: maniksurtani
>>>>>
>>>>>
>>>>>
>>>>> On 27 Oct 2006, at 13:47, Ben Wang wrote:
>>>>>
>>>>>> Manik,
>>>>>>
>>>>>> Can you clarify the semantics for the modified callbacks?
>>>>>> Specifically, I am looking at the test case:
>>>>>> CacheListenerTest.testRemoveData()
>>>>>> calling
>>>>>> cache.remove(fqn, "key2");
>>>>>> Still has the nodeModified() coming with the original data map.
>>>>>> Is this the expected behavior?
>>>>>>
>>>>>> I am hoping to see a semantics that bundles exactly the
>>>>>> modified data.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Ben
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev