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@jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org