Kezhu Wang created ZOOKEEPER-4695:
-------------------------------------
Summary: Forbid multiple mutations of one key in multi
Key: ZOOKEEPER-4695
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4695
Project: ZooKeeper
Issue Type: Wish
Components: c client, java client, server
Reporter: Kezhu Wang
I guess this might be part of ZOOKEEPER-1289, but let me list this as separated
issue for now till we got a solution for ZOOKEEPER-1289 or other committers
close this as "Duplicate".
Currently, when there are multiple mutations for one key in multi, there will
be multiple watch events delivered for that key. Let's assume {{delete}} and
{{create}} for key "/foo" in a {{multi}} operation. Client will receive two
events with {{NodeDeleted}} and {{NodeCreated}}, then client will expose a
state that "/foo" does not exist. But in normal reads, we should never
encounter such a state as {{multi}} should behave atomic.
It is absolutely a breaking change as there is new failure path or code in
client.
I think there are alternatives. One should be merging multiple mutations to one
in server side, may be solely for watch events. I guess it might be rare for
clients to depend on concrete watch types for changes. But I think this
approach might be relatively hard.
References:
* Etcd rejects multiple mutations for one key in there txns. See
[etcd-io/etcd#4363|https://github.com/etcd-io/etcd/pull/4363] and
[etcd-io/etcd#4376|https://github.com/etcd-io/etcd/pull/4376]
* ZOOKEEPER-4655([#1950|https://github.com/apache/zookeeper/pull/1950])
proposed {{WatchedEvent.zxid}} to carry the {{zxid}} triggering the delivering
event. I think this issue undermine that proposal.
* The discovery process and reason I open this issue.
[#1950|https://github.com/apache/zookeeper/pull/1950#issuecomment-1544436457]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
