It is possible to do it that way but it will be a lot easier (and more reliable) if the transaction for cleaning up the reference node was managed internally.
thanks :) On Tue, Dec 21, 2010 at 3:51 PM, Ted Dunning <[email protected]> wrote: > Sounds like you want multiple updates. > > :-) > > With that capability, you can store a back-reference in B that indicates C > points to it. When deleting > B, you would read the content of B first. THen you would read C to look > for > back references. Once you > have the closure of all nodes to be deleted, you can do a conditional > delete of all the nodes with an update > for each node that B points to with a forward reference. > > On Tue, Dec 21, 2010 at 1:10 PM, Peco Karayanev <[email protected] > >wrote: > > > Hello, > > We have a developing need for a new type of zookeeper node. I will call > it > > a > > "reference" node. We want the reference node to behave as a hybrid > between > > a > > symlink/shortcut and an ephemeral node. We want to use the reference node > > to > > keep track of dependencies between nodes (we need to represent a graph). > > Here is the scenario > > > > 1. A node is connected to B node with a reference node C. > > 2. B node is removed. > > 3. C gets automatically removed by zookeeper. > > > > This facility will ensure we can represent graphs accurately when changes > > happen to the nodes that participate. > > > > My question is: Has anyone encountered this use case, and if developers > are > > listening in has there been a discussion of implementation of this > > behavior? > > Thanks > > > > Peco > > >
