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)