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 >
