zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Kanivets (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-3049) would zookeeper transaction(multi) block the concurrent read?
Date Wed, 23 May 2018 01:05:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16486540#comment-16486540

Bogdan Kanivets commented on ZOOKEEPER-3049:

IMHO, there is a possibility.

Ops within mutli are applied in a loop without any global lock. Locking happens only on the
node within individual setData ops.

One way to protect is to check Stat.mzxid when reading znode1 and znode2. It should be the
same. Multi uses same transaction id for all ops.

> 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: Blocker
> 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

View raw message