*And from the perspective of the zk server, it handles the following two change in the shown order: a) /a changes to newA b) /b changes to newB*
Try to rephrase: In such order a) User U: create "/a" "oldA" b) User U: create "/b" "oldB" c) User S: read "/a" watch d) User E: set "/a" "newA" e) User F: set "/b" "newB" f) User S: read "/b" In step f), user S either get "oldB" for "/b" (in case he connects to a server that is a bit slow), or firstly callback for "/a" is invoked with event CHANGED, and then getData() returns with "newB" for "/b". >From my understanding, this is guaranteed. My question is, if in step e) it is not another user F, but user S that set "/b" to "newB", and from the perspective of the zk server, this write is also followed by the write in step d) (so that /a is changed before /b), does the zookeeper guarantee for user S to firstly get notified of watch set in step c) incurred by step d), and then the write to "/b" completes (by "complete", I mean the setData() return, or for "aset", completion callback invoked). Thanks. XING Dikan 2011/5/6 Ted Dunning <[email protected]> > This example seems a bit confused. > > If there is a watch on /b and /a is changed, then the watch on /b will not > be triggered. > > Can you rephrase your question? > > On Thu, May 5, 2011 at 8:47 PM, 邢迪侃 <[email protected]> wrote: > > > Hi, All, > > > > I'm not sure whether the response (from the client perspective, the > > completion callback or the return of a sync call) to a success write > > (create, delete, etc) is also queued in the right place among read > > completion and read watch. > > > > In detail, for example the current view is: > > /a: oldA > > /b: oldB > > > > And from the perspective of the zk server, it handles the following two > > change in the shown order: > > a) /a changes to newA > > b) /b changes to newB > > > > I understand, if Tom sets the read watch previously, before reading out > the > > new content of "/b", Tom will get watch notification of "/a". > > My question is if Tom is not reading, but writing. It is Tom that changes > > the content of /b. Then is there guarantee that the watch notification of > > "/a" will preceed the completion callback (if Tom asetData()) and the > > return > > of setData? > > > > In other words, will the server queue the response to the client's write > > request only after previous writes are locally played and triggered > watches > > are handled and queued into TCP sending tunnel? > > Or say, is a success response to a write request a part of a consistent > > view > > for a client? > > > > XING Dikan > > >
