Thank you for the clarification, Justin! I appreciate your example although I'm not sure it applies to the situation I observed. From what I understand, we don't have a guarantee that we can read the client's (or other clients for that matter) latest writes given strict timestamps (t1, t2, etc).
The link you sent from jepsen says the following about sequential consistency: > Informally, sequential consistency implies that operations appear to take place in some total order, and that that order is consistent with the order of operations on each individual process. This seems to match my understanding. I gave a single client example in my initial message to keep things simple but I will try to describe the situation in better detail. Suppose we have 3 clients - A, B and C. I'll mark each operation with a timestamp although they are not very relevant ``` 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? Best, Stanislav On Fri, Aug 28, 2020 at 7:15 AM Justin Ling Mao <maoling199210...@sina.com> wrote: > *---> 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.* > > You may have a misunderstanding on what *sequential consistency* > guarantees. For your example: > > Suppose that you have following operations: > > create /mypath v0 (0x11000012207) > > setData /mypath v1 (0x11000012208) > > setData /mypath v2 (0x11000012209) > > Now at the time(t1), the client setDatas *0x110000122a(v3)* successfully. > Just after the time(t1), the client still has the potential possibility to > read the value(v2), otherwise v3. (e.g.,: the client may connect to the > minority server which may receive or write the transaction log slower than > the majority due to network or disk latency, so the write is not exposed to > that client in time) > > > Generally speaking, *sequential consistency* guarantees that we don't > have the potential risk of read skew. However it doesn't guarantee that you > can always read the latest value. What you want may be *Linearizability.* > > You may be interested in these posts which have more accurate definition > on the consistency: > https://aphyr.com/posts/313-strong-consistency-models > https://jepsen.io/consistency/models/sequential > https://jepsen.io/consistency/models/linearizable > > > BTW, I am working on "*ZOOKEEPER-3600:support the complete linearizable > read and multiply read consistency level*", and I wish it will be coming > soon. > > > > ----- Original Message ----- > From: Ted Dunning <ted.dunn...@gmail.com> > To: dev@zookeeper.apache.org > Subject: Re: Sequential Consistency Guarantees > Date: 2020-08-28 02:06 > > Can you describe your evidence in more detail as you understand it? > 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 > > > -- Best, Stanislav
