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