Hi Ted, Thanks for the reply. I prefer to store the UUID in the data itself. I thought about storing it in znode names, but the downside of this approach is that when a Watcher receives an event, it needs to strip off the UUID. Otherwise, it wont be possible to figure out the order znodes (e.g., using sort()). Also, in our case, there are very few sequential children. So listing and reading all children is not a big overhead.
However, gets trickier because there is no explicit way (to my knowledge) to get CreateMode for a znode. As a result, we cannot tell whether a node is sequential or not. Thanks. -Vishal On Tue, Oct 12, 2010 at 5:36 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > 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 > > >
