<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo <span dir="ltr"><<a href="mailto:pedro@infinispan.org" target="_blank">pedro@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
simple question: What are the consistency guaranties that is supposed to<br>
be ensured?<br>
<br>
I have the following scenario (happened in a test case):<br>
<br>
NonOwner: remote get key<br>
BackupOwner: receives the remote get and replies (with the correct value)<br>
BackupOwner: put in L1 the value<br></blockquote><div><br></div><div>I assume you meant NonOwner here?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
PrimaryOwner: [at the same time] is committing a transaction that will<br>
update the key.<br>
PrimaryOwer: receives the remote get after sending the commit. The<br>
invalidation for L1 is not sent to NonOwner.<br></blockquote><div><br></div><div>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 <a href="https://issues.jboss.org/browse/ISPN-2965">https://issues.jboss.org/browse/ISPN-2965</a>).<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The test finishes and I perform a check for the key value in all the<br>
caches. The NonOwner returns the L1 cached value (==test fail).<br>
<br>
IMO, this is bug (or not) depending what guaranties we provide.<br>
<br>
wdyt?<br>
<br></blockquote><div><br></div><div>It's a bug!<br><br></div><div>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. <br>
<br>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.<br><br>
</div><div>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?<br></div><div><br><br></div></div></div></div>