[ https://issues.apache.org/jira/browse/ZOOKEEPER-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
HaiyuanZhao updated ZOOKEEPER-4743: ----------------------------------- Description: 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. As shown in the following code block {code:java} // Some comments here private static int checkAndIncVersion(int currentVersion, int expectedVersion, String path) throws KeeperException.BadVersionException { if (expectedVersion != -1 && expectedVersion != currentVersion) { throw new KeeperException.BadVersionException(path); } return currentVersion + 1; } {code} This will result in the client being unable to continue using CAS updates. In order to ensure that the client can use consistent logic to handle overflow problems. I propose that when currentVersion=-2, expectVersion=currentVersion+2 and skip the case of -1(Inspired by [~Tison],). This ensures that dataVersion will never have an overflow problem, and the client only needs to do special processing when it overflows. was: 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. > 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. As shown in the following code block > {code:java} > // Some comments here > private static int checkAndIncVersion(int currentVersion, int > expectedVersion, String path) throws KeeperException.BadVersionException { > if (expectedVersion != -1 && expectedVersion != currentVersion) { > throw new KeeperException.BadVersionException(path); > } > return currentVersion + 1; > } > {code} > This will result in the client being unable to continue using CAS updates. > In order to ensure that the client can use consistent logic to handle > overflow problems. I propose that when currentVersion=-2, > expectVersion=currentVersion+2 and skip the case of -1(Inspired by > [~Tison],). 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)