> http://www.mail-archive.com/zookeeper-dev@hadoop.apache.org/msg08317.html > > Mostly looked like this wasn¹t on our roadmap for short term, but definitely > something to think about longer term.
Nice, thanks for the pointer. This looks precisely like the kind of support we'd like to see implemented as well, except in our case it'd be create/delete rather than set. I agree with the rationale there as well: coordination gets significantly more complex if one has to deal not only with the problem at hand, but also with the intermediate states which have to be put in place towards satisfying the necessary structure. Regarding Ben's reservations, I don't share some of them: 1) Regarding blocking, the suggestion is just to group a finite number of operations together, rather than a RDB-like begin/commit transaction mechanism. The lack of these primitives means that the workaround logic people have to put in place, besides being significantly more complex to implement and understand (bugs!), also is significantly more expensive computationally than something which executed the operations at once (e.g. how expensive would it be to create two nodes, vs. creating lock/liveness nodes and putting watching in places everywhere). 2) My impression is that aborting the whole thing on any failures in the grouped operations would be pretty easy to understand and would be what most people would expect when using such a grouping primitive (why would they want grouping otherwise?). 3) Regarding partitioning, my poor understanding becomes poorer. Given all the guarantees of ordering and whatnot that ZK already has to enforce, feels like it shouldn't be significantly harder to batch things together, but I don't have enough understanding to say anything here to be honest. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter
