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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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@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
>
>