On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Oct 29, 2013, at 3:08 PM, William Burns <mudokonman(a)gmail.com> wrote:
> I agree, and I could have sworn there was a JIRA that detailed this,
> but I can't seem to locate it now. I was hoping to get to it next
> release.
+1.
>
> This also is a very big improvement for non tx caches as well as the
> updating cache only has to send a single message, possibly reducing
> the overall amount of required JGroups messages by a third.
We're already doing this for non-tx caches, at least since the lock
delegation was implemented.
> Although
> the amount of bytes reduced is only a fixed amount less.
>
> Also it would make the consistency more correct since right now there
> is technically a window where you could have 2 concurrent updates but
> only 1 sees the correct returned value.
+1
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.
>
> On Tue, Oct 29, 2013 at 9:42 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
>> Hi,
>>
>> Pedro suggested moving the following idea to separate thread (from the
>> 'Improve WriteCommand processing code...'). Re:
>>
>> I've been wondering for a while why the fetch part is a separate message
>> in the write flow. Is the return value of much use when it does not
>> return really the replaced value but only some of the previous values?
>> And this way you double* the latency. I think that returning the value
>> from primary owner as the response for write would make more sense.
>> Naturally, for optimistic txs you can only do the get, and for
>> pessimistic ones you'd have to return the value together with the
>> locking, but still, the operations would make more sense.
>>
>> *: OK, it's not doubling as with the write the primary owner replicates
>> the write to backups, but it's doubling the amount of communication
>> originating from the requestor node.
>>
>> WDYT?
+1
Care to create a JIRA for this please?
>>
>> Radim
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev