[ZOOKEEPER-4695] Forbid multiple mutations of one key in multi

• Type: Wish
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: c client, java client, server
• Assignee: Unassigned
• Reporter: Kezhu Wang
• Created: 16/May/23 15:04
• Updated: 16/May/23 15:56

Description

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 and etcd-io/etcd#4376
• ZOOKEEPER-4655(#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

Issue Links

• relates to: ZOOKEEPER-1289 Multi Op Watch Events
• relates to: ZOOKEEPER-4655 Communicate the Zxid that triggered a WatchEvent to fire