CURATOR-33 recursive TreeCache recipe

To be fair, if you get a child update event it actually includes the data with the event; but you're right, there's no possible way to ensure the node hasn't been subsequently deleted by the time you go to query the tree (even in the event callback).

I don't quite see what you're getting at with a slower consistent API short of COW.  Locking on the consumer side won't do any good unless you're also locking on the mutation side, which means you're allowing user code to block tree updates-- which seems really bad and could cause queuing problems on the mutation side while arbitrary callback code is running.

I think the only solution if you really want to see a consistent view is an immutable copy-on-write tree.  Every update would produce a new root node, and new nodes down to the point of change, so updates would be O(lg n).  Most of the nodes would be shared between each tree revision.  Once the new tree is constructed you atomically update the root reference.  You could actually attach the entire tree state to every event if you wanted.

I agree it's kind of an appealing story, but the reason it seems like overkill to me is that you can't (generally) get a consistent view of ZK anyway, and I worry about GC pressure of creating so many objects.  But I could be convince to take a crack at this approach.