Re: Parent nodes multi-step transactions

Hi Gustavo, I have a very strong feeling against more complex operations in the ZK server. These are things that should be provided by a ZK client helper library. The zkclient library from 101tec for example gives you exactly that. If you're planning to write another layer on top of the ZK API

Re: Parent nodes multi-step transactions

My own opinion is that lots of these structure sorts of problems are solved by putting the structure into a single znode.  Atomic creation and update come for free at that point and we can even make the node ephemeral which we can't really do if there are children. Sure, it makes sense that

Re: Parent nodes multi-step transactions

Hi Thomas, I have a very strong feeling against more complex operations in the ZK server. Can you please describe a little better what that feeling is about? These are things that should be provided by a ZK client helper library. The Which things should be provided by client helper

Re: Parent nodes multi-step transactions

Gustavo Niemeyer: Hi Thomas, I have a very strong feeling against more complex operations in the ZK server. Can you please describe a little better what that feeling is about? Every functionality added to ZK will make it harder to maintain. The use case you're asking for is IMHO easily

Parent nodes multi-step transactions

Greetings, We (a development team at Canonical) are stumbling into a situation here which I'd be curious to understand what is the general practice, since I'm sure this is somewhat of a common issue. It's quite easy to describe it: say there's a parent node A somewhere in the tree. That node

Re: Parent nodes multi-step transactions

Hi Gustavo, Usually the paradigm I like to suggest is to have something like /A/init Every client watches for the existence of this node and this node is only created after /A has been initialized with the creation of /A/C or other stuff. Would that work for you? Thanks mahadev On 8/23/10

Re: Parent nodes multi-step transactions

Hi Mahadev,  Usually the paradigm I like to suggest is to have something like /A/init Every client watches for the existence of this node and this node is only created after /A has been initialized with the creation of /A/C or other stuff. Would that work for you? Yeah, this is what I

Re: Parent nodes multi-step transactions

For my $0.02, I really think it would be nice if ZK supported lightweight transactions. By that, I simply mean that a batch of create/update/delete requests could be submitted in a single request, and be processed atomically (if any of the requests would fail, none are applied). I know