So, getting back to the original problem, I think that you need to specify
it more tightly in order to solve it. Otherwise, when you find problems in
a solution you won't know whether those are problems with the solution or
the original problem statement.
As I see it, there are several possible meanings of what you are asking for.
One possible specification is that you want a createOrSet such that it has
one value if the znode was created and a different value if it was
modified. It is important to allow various other operations before or after
this operation.
Another possible specification that I would dismiss for now is a general
atomic if-else capability. That is a bit much for me to handle in the
morning. :-)
So...
firstly, you could just do this:
while (true) {
if (create(...)) break;
if (set(...)) break; // could not succeed
}
This is actually a very practical solution that will only ever iterate if
it collides with another mutation in flight and it will have all of the
atomic properties that we would like because only one of the create or set
will ever succeed.
If you have almost *any* constraints on the updates that other machines
will make to this znode, then you can prove that this loop is a good
implementation. For instance, if there is a limit on the frequency of
updates. Or if nodes will never delete the znode. Or ... many other kinds
of constraint.
You should, of course, check the returned values to be sure that the
failures are not due to permissions, but are, in fact, due to the node
existing at the time of the create or not existing at the time of the set.
So this is a practical solution even if not a theoretically nice one.
If you really want a solution that has theoretical guarantees, you can use
this instead:
lock (znode-twin) {
create(...) || set(...)
}
Here you would use a standard ZK idiom to create a lock. One simple and
pretty standard version is to try to create a node with a watch. If the
create fails, wait for the watch to trigger and try again. Once the create
succeeds, do your stuff and delete the znode as you leave. There are lock
implementations that implement fair waiting at the cost of just a bit more
complexity.
This alternative requires more ZK operations (create lock, create, maybe
set, delete lock) and requires two znodes. If you use a fair lock
implementation, you are have better completion guarantees.
Does this do what you want?
On Wed, Aug 14, 2019 at 11:04 PM Zili Chen <wander4...@gmail.com> wrote:
> Thanks for your explanation Michael and Ted :-)
>
> Best,
> tison.
>
>
> Ted Dunning <ted.dunn...@gmail.com> 于2019年8月15日周四 下午1:22写道：
>
> > As Michael correctly said, isolation only makes sense when you allow
> > concurrent queries. Of the four ACID properties, the multi op satisfies
> A,
> > C and D while I is essentially irrelevant (or could be said to be
> trivially
> > satisfied since there are no concurrent queries.
> >
> >
> > On Wed, Aug 14, 2019 at 6:45 PM Zili Chen <wander4...@gmail.com> wrote:
> >
> > > Thanks for your reply Ted.
> > >
> > > I cannot understand the statement "That leaves isolated which is kind
> of
> > > hard to talk about with ZK since all operations are fast and
> sequential."
> > > well. Could you explain a bit? What is "that" means and where is the
> > "hard"
> > > comes from?
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Ted Dunning <ted.dunn...@gmail.com> 于2019年8月15日周四 上午9:40写道：
> > >
> > > > The multi op is atomic (all other operations will be before or after
> > teh
> > > > multi), consistent (all viewers will see all the effects or none, and
> > > > durable (because ZK is linearized anyway).
> > > >
> > > > That leaves isolated which is kind of hard to talk about with ZK
> since
> > > all
> > > > operations are fast and sequential.
> > > >
> > > > On Wed, Aug 14, 2019 at 3:12 PM Michael Han <h...@apache.org> wrote:
> > > >
> > > > > ...
> > > > > Ted can correct me if I am wrong, since he added the multi op
> > feature,
> > > > but
> > > > > my understanding is "multi op" is branded from day one as the
> > > transaction
> > > > > support for zookeeper (we even provide an API with exact name:
> > > > > Transaction). If we use the traditional semantic for transaction in
> > > > > database context, the ACID properties multi-op satisfies at least
> > > > atomicity
> > > > > and durability. So saying zookeeper does not support transaction
> > seems
> > > a
> > > > > strong argument that against the properties of multi-op and
> existing
> > > > > literatures related to zookeeper. On the other side, typically bulk
> > > > > operations does not support atomicity, which will not take care of
> > > > rolling
> > > > > back failed operations.
> > > > >
> > > >
> > > >
> > > > >
> > > >
> > >
> >
>
