Re: [infinispan-dev] Retrieving value before write
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.
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. 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.
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?
Radim
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev