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 > [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 -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
