<div dir="ltr"><div>Radim, I would contend that the first and foremost guarantee that put() makes is to leave the cache in a consistent state. So we can't just throw an exception and give up, leaving k=v on one owner and k=null on another.</div>
<div><br></div><div>Secondly, put(k, v) being atomic means that it either succeeds, it writes k=v in the cache, and it returns the previous value, or it doesn't succeed, and it doesn't write k=v in the cache. Returning the wrong previous value is bad, but leaving k=v in the cache is just as bad, even if the all the owners have the same value.</div>
<div><br></div><div>And last, we can't have one node seeing k=null, then k=v, then k=null again, when the only write we did on the cache was a put(k, v). So trying to undo the write would not help.</div><div><br></div>
<div>In the end, we have to make a compromise, and I think returning the wrong value in some of the cases is a reasonable compromise. Of course, we should document that :)</div><div><br></div><div>I also believe ISPN-2956 could be fixed so that HotRod behaves just like embedded mode after the ISPN-3422 fix, by adding a RETRY flag to the HotRod protocol and to the cache itself.</div>
<div><br></div><div>Incidentally, transactional caches have a similar problem when the originator leaves the cluster: ISPN-3421 [1]</div><div>And we can't handle transactional caches any better than non-transactional caches until we expose transactions to the HotRod client.</div>
<div><br></div><div>[1] <a href="https://issues.jboss.org/browse/ISPN-2956">https://issues.jboss.org/browse/ISPN-2956</a></div><div><br></div><div>Cheers</div><div>Dan</div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, May 12, 2014 at 10:21 AM, Radim Vansa <span dir="ltr"><<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
recently I've stumbled upon one already expected behaviour (one instance<br>
is [1]), but which did not got much attention.<br>
<br>
In non-tx cache, when the primary owner fails after the request has been<br>
replicated to backup owner, the request is retried in the new topology.<br>
Then, the operation is executed on the new primary (the previous<br>
backup). The outcome has been already fixed in [2], but the return value<br>
may be wrong. For example, when we do a put, the return value for the<br>
second attempt will be the currently inserted value (although the entry<br>
was just created). Same situation may happen for other operations.<br>
<br>
Currently, it's not possible to return the correct value (because it has<br>
already been overwritten and we don't keep a history of values), but<br>
shouldn't we rather throw an exception if we were not able to fulfil the<br>
API contract?<br>
<br>
Radim<br>
<br>
[1] <a href="https://issues.jboss.org/browse/ISPN-2956" target="_blank">https://issues.jboss.org/browse/ISPN-2956</a><br>
[2] <a href="https://issues.jboss.org/browse/ISPN-3422" target="_blank">https://issues.jboss.org/browse/ISPN-3422</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
JBoss DataGrid QA<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>
</font></span></blockquote></div><br></div>