[infinispan-dev] Retrieving value before write

[William Burns]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev