Yes. This is indeed a problem. I generally try to avoid sequential nodes unless they are ephemeral and if I get an error on creation, I generally have to either tear down the connection (losing all other ephemeral nodes in the process) or scan through all live nodes trying to determine if mine got created. Neither is a very acceptable answer so I try to avoid the problem.
Your UUID answer is one option. At least you know what file got created (or not) and with good naming you can pretty much guarantee no collisions. You don't have to scan all children since you can simply check for the existence of the file of interest. There was a JIRA filed that was supposed to take care of this problem, but I don't know the state of play there. On Tue, Oct 12, 2010 at 12:11 PM, Vishal K <vishalm...@gmail.com> wrote: > Hi, > > What is the best approach to have an idempotent create() operation for a > sequential node? > > Suppose a client is trying to create a sequential node and it gets a > ConnectionLoss KeeperException, it cannot know for sure whether the request > succeeded or not. If in the meantime, the client's session is > re-established, the client would like to create a sequential znode again. > However, the client needs to know if its earlier request has succeeded or > not. If it did, then the client does not need to retry. To my understanding > ZooKeeper does not provide this feature. Can someone confirm this? > > External to ZooKeeper, the client can either set a unique UUID in the path > to the create call or write the UUID as part of its data. Before retrying, > it can read back all the children of the parent znode and go through the > list to determine if its earlier request had succeeded. This doesn't sound > that appealing to me. > > I am guessing this is a common problem that many would have faced. Can > folks > give a feedback on what their approach was? > > Thanks. > -Vishal >
