[infinispan-dev] Retrieving value before write

[William Burns]

On Tue, Oct 29, 2013 at 12:58 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>
>
>
> On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>>
>>
>> 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
>
>
> 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.

Yeah unfortunately what I said was thinking before lock delegation
rewrite that Mircea mentioned.  Looking at it again I would agree non
tx and pessimistic would be fine.

>
>>
>>
>> >
>> > 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)
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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