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?
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org