Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of scottfines@gmail.com
 designates 209.85.215.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=QE/ndy7cZsJEpT/oTzdfiHF++pL8c6dNtKbPqGAz+zRppRFi5L/32Bt9EjoRn/W6su
         KAFkhkLMk3jgXNPNt4GDuVfbwSzTx3Ph/nHRSVXKTOsY4FfKt+P6oDJbKdTGsWiUrJ2L
         IKsIfXGvLRs8MX0De2SOdQ+hljWGrKirwtsQc=
MIME-Version: 1.0
Date: Sat, 15 Jan 2011 10:14:31 -0600
Message-ID: <AANLkTi=hUr1qbJbupwxeE=OAeX5w1mVVJ+nHMaMRVbM5@mail.gmail.com>
Subject: Atomic Compare-and-swap like operations
From: Scott Fines <scottfines@gmail.com>
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=90e6ba6154b68bb0920499e4d821

--90e6ba6154b68bb0920499e4d821
Content-Type: text/plain; charset=ISO-8859-1

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
operation.

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>
could
potentially address this in the future, but it seems like API overkill for
something like this.

--90e6ba6154b68bb0920499e4d821--