<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</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>
On Oct 29, 2013, at 3:08 PM, William Burns <<a href="mailto:mudokonman@gmail.com">mudokonman@gmail.com</a>> wrote:<br>
<br>
> I agree, and I could have sworn there was a JIRA that detailed this,<br>
> but I can't seem to locate it now. I was hoping to get to it next<br>
> release.<br>
<br>
</div>+1.<br>
<div class="im"><br>
><br>
> This also is a very big improvement for non tx caches as well as the<br>
> updating cache only has to send a single message, possibly reducing<br>
> the overall amount of required JGroups messages by a third.<br>
<br>
</div>We're already doing this for non-tx caches, at least since the lock delegation was implemented.<br>
<div class="im"><br>
> Although<br>
> the amount of bytes reduced is only a fixed amount less.<br>
><br>
> Also it would make the consistency more correct since right now there<br>
> is technically a window where you could have 2 concurrent updates but<br>
> only 1 sees the correct returned value.<br>
<br>
</div>+1<br></blockquote><div><br></div><div>I'm not sure about that... in non-tx caches we already return the previous value from the write command, and in pessimistic caches we acquire the remote lock *before* we retrieve the value.<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"><br>
><br>
> On Tue, Oct 29, 2013 at 9:42 AM, Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> Pedro suggested moving the following idea to separate thread (from the<br>
>> 'Improve WriteCommand processing code...'). Re:<br>
>><br>
>> I've been wondering for a while why the fetch part is a separate message<br>
>> in the write flow. Is the return value of much use when it does not<br>
>> return really the replaced value but only some of the previous values?<br>
>> And this way you double* the latency. I think that returning the value<br>
>> from primary owner as the response for write would make more sense.<br>
>> Naturally, for optimistic txs you can only do the get, and for<br>
>> pessimistic ones you'd have to return the value together with the<br>
>> locking, but still, the operations would make more sense.<br>
>><br>
>> *: OK, it's not doubling as with the write the primary owner replicates<br>
>> the write to backups, but it's doubling the amount of communication<br>
>> originating from the requestor node.<br>
>><br>
>> WDYT?<br>
<br>
</div>+1<br>
Care to create a JIRA for this please?<br>
<div> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
>><br>
>> Radim<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>
> _______________________________________________<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>
</div>Cheers,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<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>