zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Fines <scottfi...@gmail.com>
Subject Atomic Compare-and-swap like operations
Date Sat, 15 Jan 2011 16:14:31 GMT
Hello All,

So I've been working on an implementation of a BlockingQueue for
Menagerie<http://github.com/openUtility/menagerie> (shameless
plug!), and I keep running into complications because of some compound
actions, so I thought I would bring it up to the community at large.

To fully implement a java.util.concurrent.BlockingQueue, you need to
implement a take() operation that blocks until an entry is added, then get
the data for that entry and delete it. Unfortunately, the ZooKeeper API
makes getting data from a znode a distinct, separate action from a delete
operation which isn't atomic. Thus, in order to perform a take, I have to
first grab a distributed Lock on the head node, just because a
delete-and-get operation is not atomic. This seems very much like excessive
locking that could be easily circumvented with an atomic get-and-delete

It seems like it would be a very powerful option to be able to have a
"delete-and-return" operation that atomically deletes a znode, and returns
the bytes that were previously stored in that znode. Is there a particular
reason why this was not chosen as the behavior of the API? In most of the
other generic compare-and-swap operations (put-if-absent and
set-if-matches), there is already a mechanism in place, or one can
relatively easily be implemented, but this seems like an odd oversight.

I saw that ZooKeeper-965<https://issues.apache.org/jira/browse/ZOOKEEPER-965>
potentially address this in the future, but it seems like API overkill for
something like this.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message