zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: thoughts about extension to multi semantics
Date Sat, 17 Aug 2019 12:29:56 GMT
Il sab 17 ago 2019, 08:01 Ted Dunning <ted.dunning@gmail.com> ha scritto:

> It definitely sounds like a nice feature.
>
> The important question is what is the actual importance after you multiply
> it by the amount of usage it gets.
>
> For instance, I know that multi gets a bit of usage, but I would guess that
> it actually gets very, very little. It might even most of the cases that
> you have in mind.
>
> If that is so, how much would an extension to multi actually be used?
>

I am adding a question: how will the 'test' look like? I image these cases:
- test if node exists
- test about version
- test about the content of the znode? (This will be trickers, are zk does
know nothing about the format of the content)


Enrico



>
>
> On Fri, Aug 16, 2019 at 8:28 PM Michael Han <hanm@apache.org> wrote:
>
> > This sounds a nice feature to me as it enables user to do more without
> > obvious downside. It could be useful in cases like state management where
> > the state is stored in a fine grained approach across multiple zNode,
> > instead of in a single zNode.
> >
> > On Fri, Aug 16, 2019 at 11:52 AM Ted Dunning <ted.dunning@gmail.com>
> > wrote:
> >
> > > The recent discussion about if/then/else idioms in ZK has raised the
> > > thought that it might be nice to have some extended semantics.
> > >
> > > One version that I could see would be to to extend the current multi-op
> > to
> > > allow multiple alternatives. The idea would be that there would
> > effectively
> > > be multiple branches to be tried. The first one that succeeds
> atomically
> > > (all or nothing) would be used. The returned value would need to
> somehow
> > > indicate which alternative succeeded and would need to return any data
> > > accessed. The testing of alternatives would also be atomic so it
> wouldn't
> > > be possible for things to change within a single operation.
> > >
> > > This extension would allow the previous question to be answered like
> > this:
> > >
> > >            pick_first {
> > >                  create(...)
> > >            } {
> > >                  set(...)
> > >            }
> > >
> > > (the syntax here is just made up and wouldn't actually be supported ...
> > it
> > > is just for pseudo code purposes).
> > >
> > >
> > > My theory is that this would be relatively easy to implement based on
> the
> > > current multi operation. Risk due to the change is pretty low given
> that
> > > there is code to copy.
> > >
> > > My question is whether this would actually have all that much benefit.
> > >
> > > Does anybody have an opinion on that?
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message