ZK provides strict and identical ordering of updates from the viewpoint of any particular client. Reads will always see versions of znodes that correspond to monotonically increasing changes. I am pretty (99%) sure that interleaved reads and writes on the same machine will give consistent results from the point of view of that client.
2011/5/5 邢迪侃 <[email protected]> > *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 > > > > > >
