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 [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
