I must not understand your question fully as cases (1) and (2) look very similar. It looks like you are trying to provide "atomic" access to the data in both cases. It looks like case (2) is a special case of case (1) in that only one of the processes is allowed to access the node and delete it.
If my understanding above is correct, you may be able to do the following for case (1). You can make your processes coordinate by using a distributed lock (implemented using ZK) to guard access to the node. Once you have the lock, you can do whatever you want to the node without fear that others are acting on it. You can find example lock code in the ZK docs<http://zookeeper.apache.org/doc/r3.4.5/recipes.html#sc_recipes_Locks>or you could use the Curator lib <https://github.com/Netflix/curator> to implement the lock. As for case (2), you don't need a lock since only one process is allowed to access it. You could create the node name with a pattern such that you know it should only be processed by process4. For example, you might have the following hierarchy of znodes: - /myapp - /myapp/case1nodes - /myapp/case2nodes Process4 and your other processes would know that only process4 is allowed to process nodes in /myapp/case2nodes. If you need to elect a process to be "process4", you can use ZK to implement an election (see this link<http://zookeeper.apache.org/doc/r3.4.5/recipes.html#sc_leaderElection> for a ZK recipe). wt On Sun, Sep 15, 2013 at 10:27 PM, fengguang gong <[email protected]>wrote: > Hi all： > when a znode is updated, there are four processes(1.2.3.4)can access the > znode. > Two cases: > (1)what i need is that there is only one process execute getData and > delete atomically. > (2)what i need is that process4 execute getData and delete atomically. > In case (1), EPHEMERAL_SEQUENTIAL will be used. > In case (2), what should i do?
