On 07/02/2013 04:29 PM, Dan Berindei wrote: > > > > On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo <pe...@infinispan.org > <mailto:pe...@infinispan.org>> wrote: > > Hi all, > > simple question: What are the consistency guaranties that is supposed to > be ensured? > > I have the following scenario (happened in a test case): > > NonOwner: remote get key > BackupOwner: receives the remote get and replies (with the correct > value) > BackupOwner: put in L1 the value > > > I assume you meant NonOwner here?
yes > > PrimaryOwner: [at the same time] is committing a transaction that will > update the key. > PrimaryOwer: receives the remote get after sending the commit. The > invalidation for L1 is not sent to NonOwner. > > > At some point, BackupOwner has to execute the commit as well, and it > should send an InvalidateL1Command(key) to NonOwner. However, one of the > bugs that Will is working on could prevent that invalidation from > working (maybe https://issues.jboss.org/browse/ISPN-2965). only the primary owner is sending the invalidation command. > > > The test finishes and I perform a check for the key value in all the > caches. The NonOwner returns the L1 cached value (==test fail). > > IMO, this is bug (or not) depending what guaranties we provide. > > wdyt? > > > It's a bug! > > IMO, at least in DIST_SYNC mode with sync commit, we should guarantee > that stale entries are removed from non-owners before the TM.commit() > call returns on the originator. > > With other configurations we probably can't guarantee that, instead we > should guarantee that stale entries are removed from non-owners "soon" > after the TM.commit() call returns on the originator. > > I don't think it's ok to say that a stale entry can stay in L1 > indefinitely in any configuration - otherwise why have L1 invalidation > at all? > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev