[infinispan-dev] Retrieving value before write

[Mircea Markus]

On Oct 29, 2013, at 3:08 PM, William Burns <mudokonman at 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

> 
> 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?

+1
Care to create a JIRA for this please?


>> 
>> Radim
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)