[jbosscache-dev] JBCACHE-388 Provide modified data in callbacks

[Manik Surtani]

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,

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 30 Oct 2006, at 15:53, Ben Wang wrote:

> 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 at redhat.com]
> Sent: Monday, October 30, 2006 11:15 PM
> To: Ben Wang
> Cc: jbosscache-dev at 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 at redhat.com
> Telephone: +44 7786 702 706
> MSN: manik at 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 at redhat.com]
>> Sent: Friday, October 27, 2006 11:14 PM
>> To: Ben Wang
>> Cc: jbosscache-dev at 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 at redhat.com
>> Telephone: +44 7786 702 706
>> MSN: manik at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>