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 <rva...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev