[
https://issues.apache.org/jira/browse/ZOOKEEPER-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765666#comment-17765666
]
Zili Chen commented on ZOOKEEPER-4743:
--------------------------------------
Thanks for reporting this issue [~zhaohaidao]! Generally the proposal looks
good. One comment below:
> When expectedVersion==0 and currentVersion==-1, the dataVersion update will
> fail.
This is not the case. The real issue is that, when:
* expectedVersion==-2, the next expectedVersion==-1, which will be ambiguous
with wildcard matcher.
We skip -1 when counting from Integer.MINVALUE to 0 to avoid ambiguity.
> Jump from -2 to 0 when zookeeper increments znode dataVersion
> -------------------------------------------------------------
>
> Key: ZOOKEEPER-4743
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4743
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: HaiyuanZhao
> Priority: Major
>
> DataVersion is a 32-bit signed integer. When dataVersion exceeds Integer.MAX,
> an overflow problem will occur.
> According to my own understanding, overflow itself is not a big problem. The
> core of dataVersion is to describe the causal order. Two different values
> can be used to determine the happened-before relationship between the two.
> Then even if an overflow occurs, except for the scenario where Integer.MAX is
> larger than Integer.MAX+1, compared with any value in other scenarios and the
> value + 1, the latter is always larger than the former. As described above
> for the role of dataVersion, if it continues to increase after overflow, the
> role will still take effect.
> It is also worth noting that zookeeper has special processing for
> dataVersion=-1. When expectedVersion==0 and currentVersion==-1, the
> dataVersion update will fail. This will result in the client being unable to
> continue using CAS updates.
> Inspired by [~tison], I propose that when currentVersion=-2,
> expectVersion=currentVersion+2 and skip the case of -1. This ensures that
> dataVersion will never have an overflow problem, and the client only needs to
> do special processing when it overflows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
