[infinispan-dev] L1 consistency for transactional caches.

[Dan Berindei]

On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo <pedro at 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?


> 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).


>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130702/0fb958ff/attachment.html