<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 2, 2013 at 6:35 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 07/02/2013 04:29 PM, Dan Berindei wrote:<br>
><br>
><br>
><br>
> On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a><br>
</div><div class="im">> <mailto:<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>>> wrote:<br>
><br>
> 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<br>
> value)<br>
> BackupOwner: put in L1 the value<br>
><br>
><br>
> I assume you meant NonOwner here?<br>
<br>
</div>yes<br>
<div class="im"><br>
><br>
> 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>
><br>
><br>
> At some point, BackupOwner has to execute the commit as well, and it<br>
> should send an InvalidateL1Command(key) to NonOwner. However, one of the<br>
> bugs that Will is working on could prevent that invalidation from<br>
> working (maybe <a href="https://issues.jboss.org/browse/ISPN-2965" target="_blank">https://issues.jboss.org/browse/ISPN-2965</a>).<br>
<br>
</div>only the primary owner is sending the invalidation command.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br></div><div>Oops, you're right! And I'm pretty sure I made the same assumptions in my replies to Will's L1 thread...<br><br></div><div>I guess we could make it work either sending the invalidations from all the owners (slowing down writes, because most of the time we'd send the same commands twice), or by sending remote get commands ONLY to the primary owner (which will slow down remote reads).<br>
<br></div><div>Staggering remote GET commands won't work, because with staggering you still have the possibility of the first request reaching the primary owner only after the second request returned and the entry was written to L1.<br>
<br></div><div>Sending the invalidations from the tx originator after the commit might work as well, but only if L1.invalidationTreshold == 0 and all the L1 invalidations are sent as multicasts.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb">
><br>
><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>
><br>
> It's a bug!<br>
><br>
> IMO, at least in DIST_SYNC mode with sync commit, we should guarantee<br>
> that stale entries are removed from non-owners before the TM.commit()<br>
> call returns on the originator.<br>
><br>
> With other configurations we probably can't guarantee that, instead we<br>
> should guarantee that stale entries are removed from non-owners "soon"<br>
> after the TM.commit() call returns on the originator.<br>
><br>
> I don't think it's ok to say that a stale entry can stay in L1<br>
> indefinitely in any configuration - otherwise why have L1 invalidation<br>
> at all?<br>
><br>
><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>