On Tue, Oct 29, 2013 at 12:58 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > > > > On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus <mmar...@redhat.com> wrote: >> >> >> On Oct 29, 2013, at 3:08 PM, William Burns <mudokon...@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 <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? >> >> +1 >> Care to create a JIRA for this please? >> >> >> >> >> >> >> 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 >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev