[ https://issues.apache.org/jira/browse/ZOOKEEPER-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489357#comment-16489357 ]
Fangmin Lv commented on ZOOKEEPER-3049: --------------------------------------- [~wayne sun] yes, it's kind of atomic, but guarantees from CommitProcessor, what [~bkanivets] pointed is the CommitProcessor logic where it will either processing bunch of reads or processing a single write, check the isProcessingCommit before processing read. The master code is a bit different but same idea. > would zookeeper transaction(multi) block the concurrent read? > ------------------------------------------------------------- > > Key: ZOOKEEPER-3049 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3049 > Project: ZooKeeper > Issue Type: Wish > Components: documentation > Reporter: wayne > Priority: Major > > For instance, the original data for znode1 and znode2 are 2 and 4 > respectively. I want to perform increment operations over them. Finally, I > would get (3, 5) for znode1 and znode2. In order to keep atomicity, I used > multi() api. Is there any possibility that any clients could read (3, 4) > concurrently? That is, the read happened after znode1++ and before znode2++? -- This message was sent by Atlassian JIRA (v7.6.3#76005)