Did the client respect read your write consistency？

[lsytj0413]

I have read the client's implement，and as far as i understand：

• the client will batch the request, and omit it when timeout or batch count is exceeded
• there is two batcher exists: write batch & read batch

So, there is 2 scene:

• client async send an put、get request, but get request is send to server before put, so the get request will got nothing
• client async send an delete、put request, when after the response, send an get request and got nothing（this is because write batch will reorder it as put、delete request）

Did this will happen？

[merlimat]

This is still maintaining the read-after-write semantic.

When you issue multiple async requests (put, get, delete), without waiting for their completion, the order in which the operations are applied does not have to necessarily be guaranteed.

What it's important to guarantee is that after a successful put/delete operation is completed, every other subsequent request will see the effect of the previous operation.

[lsytj0413]

But when user execute the same async request sequence multi times, it maybe got different results base on the batch opportunity. Should we keep the async operation's order in the same session if user request it in an determined order？

[merlimat]

We could, though the only way would be to couple write&read operations in a single batch, and it will make things more expensive on the server side (as well as impact the read latency, since it will have to wait until the write completes).

From my perspective, the "read-after-write" semantic only applies to write that are already completed. For in-flight writes, it is fine to have undetermined behavior.

If one needs to have the precise semantic, it can always chain the 2 operations.

[lsytj0413]

It surprised me that even asynchronous requests cannot guarantee the order of requests despite having a clear order of issuance (within the same session). Products like ETCD didn't provide asynchronous interfaces. Is there any other similar product that uses this approach?

[merlimat]

ZK has async interface, though it does not provide strict read-after-write, not even after a write is confirmed.

eg: write goes through leader, though client is reconnected to new follower which might have not yet applied the change, thus returning the old value

[merlimat]

One other update here.

We have strengthened the ordering semantics of write/delete operations by swtichting to use a WriteStream instead of individual RPCs per each batch.

It's now guaranteed that issuing multiple async requests

eg:

future1 = putAsync("k1", "v1")
future2 = putAsync("k1", "v2")

future1.get()
future2.get()

will be guaranteed to be applied in order