[infinispan-dev] Retrieving value before write

[Dan Berindei]

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.


>
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131029/5ce89f24/attachment.html