[infinispan-dev] Design of temote event handling in Hot Rod
Galder Zamarreño
galder at redhat.com
Wed Feb 22 08:53:10 EST 2012
On Feb 22, 2012, at 12:57 PM, Manik Surtani wrote:
>
> On 22 Feb 2012, at 09:46, Galder Zamarreño wrote:
>
>> 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.
>
> Client A and Client B are two threads in the same VM as the embedded cache with a remote cache store?
Maybe, but not necessarily. It could very easily happen that Client A and Client B are running on the same machine but in different VMs.
>
> --
> 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