@ Stanislav Thanks for giving an example to help us to get your idea quickly. Just as Ted said, If C read 0x11000012209 at t4, we have a guarantee to read v1(0x11000012208), not possible to read v0 (0x11000012207) Since the write is linearizable, all the writes are ordered with a monotonically increasing zxid.If the client C read 0x11000012209, which indicates the write(0x11000012209) is committed, we guarantee that all the previous write which had been acknowledged by quorum must have been committed. Even if the client C reconnects to another server due to some reasons during this process, the server will reject the client's requests to avoid stale read when its last zxid is less than the last zxid the client C has seen ----- Original Message ----- From: Ted Dunning <ted.dunn...@gmail.com> To: dev@zookeeper.apache.org Cc: maoling199210...@sina.com Subject: Re: Re: Sequential Consistency Guarantees Date: 2020-09-02 00:03
Stanislav, A ZK client should only ever see state move forward in terms of ZXID. This is true even if a client disconnects and reconnects. If you have multiple connections to a ZK cluster, each connection will satisfy this constraint with respect to itself, but one could be behind the other. Sync can be used to force a stricter relationship. On Tue, Sep 1, 2020 at 7:35 AM Stanislav Kozlovski <stanis...@confluent.io> wrote: > ... > > ``` > t1: A creates /myPathA v0 (0x11000012207) > t2: A setData /myPathA v1 (0x11000012208) > t3: B creates /myPathB v0 (0x11000012209) > t4: C reads /myPathB > t5: C reads /myPathA > ``` > > Given that, at t4, C read 0x11000012209, do we have a guarantee that at t5 > C read v1 of /myPathA (0x11000012208)? > Is it possible that it could read v0 (0x11000012207) under some edge > conditions? > >
