[infinispan-dev] L1 consistency for transactional caches.

[Pedro Ruivo]

On 07/02/2013 04:29 PM, Dan Berindei wrote:
>
>
>
> On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo <pedro at infinispan.org
> <mailto: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?

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>