On 07/02/2013 04:29 PM, Dan Berindei wrote:
On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo <pedro(a)infinispan.org
<mailto:pedro@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev