Hi Ted, Thanks a lot for your email.
I don't stick to a general atomic if-else capability. It comes from a function in etcd community[1] and I'm curious whether ZooKeepr has cover this capability. Follow this thread I got the idea that a multi operation is like a transaction, succeed or fail together, and inherent "isolated". The case you take about "lock" implementation and do what I mean with holding the lock is what I'm actually facing. Since it is diverged from the title of this thread. I would rephrase and start a new thread later. Thank you again :-) Best, tison. [1] https://godoc.org/github.com/coreos/etcd/clientv3#OpTxn Ted Dunning <ted.dunn...@gmail.com> 于2019年8月16日周五 上午1:28写道： > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
