[infinispan-dev] Design of temote event handling in Hot Rod
Galder Zamarreño
galder at redhat.com
Wed Feb 22 04:46:22 EST 2012
On Feb 21, 2012, at 5:42 PM, Manik Surtani wrote:
>
> On 21 Feb 2012, at 16:00, Galder Zamarreño wrote:
>
>>>
>>> * Not sure I get the "option #1" in your doc? If you cared about locally originating events (and want to behave differently), you'd just register that listener using the embedded API and not the remote one?
>>
>> Hmmm, not sure I understand your question…
>
> Lets start with explaining the scenario you detailed in option 1. :)
I thought I had made myself clear enough with the wiki and explanation on the email. Let me try again:
Imagine a near cache scenario:
1. Client A interacts with a near cache (i.e. embedded Infinispan with a remote cache store) and stores V1 in key=k
2. Client B interacts with near cache and retrieves key=k. The req goes to server and returns V1
3. Client B goes and updates key=k to V2
4. Client A receives a notification for key=k that it has been updated and it decides to delete it from the near cache.
5. Client B receives a notification for key=k that it has been updated and it decides to delete it from the near cache.
Step 5. is suboptiomal because the update originiates at Client B.
The idea of the "origin" is that the server could potentially be able to tell client B that the notification is the result of an operation that started 'locally' and so client B could read that and decide to not delete it from the near cache.
Client A when it receieves the notification it realises that the notification is not originated locally and can decide to delete the key from the near cache.
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
More information about the infinispan-dev
mailing list