I think that the answer depends a bit on what you mean by "client". If you mean client connection (as in the result of opening a connection to a Zookeeper cluster), then you should see things in order so that reads following a successful and acknowledged commit should see only states at or after that commit. Even if there is a loss of connection with the cluster, the client will take measures to make sure it does not regress when connecting to a different ZK server.
If, on the other hand, by client you mean a program that is not a ZK server, then that client could see inconsistent behavior if it has more than one connection to the ZK cluster or if it closes and reopens the connection to the cluster. On Thu, Aug 27, 2020 at 10:26 AM Stanislav Kozlovski <stanis...@confluent.io> wrote: > Hello! > > We were investigating an issue with consistent reads in ZK which made us > question our assumptions. > We believe that ZK offers sequential consistency such that if a client > creates a node with zxid 0x110000122a, it should be able to see (read) all > data changes at least up to that zxid. > > Could I ask if this is a correct understanding? We seem to be seeing > evidence that's pointing towards the opposite direction. > > Looking at the documentation > < > https://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#ch_zkGuarantees > >, > it does not seem to address this specific point. It says that "Updates from > a client will be applied in the order that they were sent" and talks about > "Consistent Cross-Client Views" but does not seem to address cross-client > update order, unless I'm missing something. > > -- > Best, > Stanislav >
