Return-Path: 
 <user-return-2549-apmail-zookeeper-user-archive=zookeeper.apache.org@zookeeper.apache.org>
Delivered-To: apmail-zookeeper-user-archive@www.apache.org
Received: (qmail 69540 invoked from network); 10 Dec 2010 08:01:54 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 10 Dec 2010 08:01:54 -0000
Received: (qmail 29633 invoked by uid 500); 10 Dec 2010 08:01:53 -0000
Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org
Received: (qmail 29365 invoked by uid 500); 10 Dec 2010 08:01:53 -0000
Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@zookeeper.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@zookeeper.apache.org>
List-Post: <mailto:user@zookeeper.apache.org>
List-Id: <user.zookeeper.apache.org>
Reply-To: user@zookeeper.apache.org
Delivered-To: mailing list user@zookeeper.apache.org
Received: (qmail 29210 invoked by uid 500); 10 Dec 2010 08:01:52 -0000
Delivered-To: apmail-hadoop-zookeeper-user@hadoop.apache.org
Received: (qmail 29202 invoked by uid 99); 10 Dec 2010 08:01:52 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Dec 2010 08:01:52 +0000
X-ASF-Spam-Status: No, hits=1.5 required=10.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of yeqian.zju@gmail.com
 designates 209.85.215.43 as permitted sender)
Received: from [209.85.215.43] (HELO mail-ew0-f43.google.com) (209.85.215.43)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Dec 2010 08:01:47 +0000
Received: by ewy22 with SMTP id 22so2611813ewy.2
        for <multiple recipients>; Fri, 10 Dec 2010 00:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:cc:content-type;
        bh=ypfNATROy2dLuGcv2qKSosLIXtcbC2xAk1VQED8M5hs=;
        b=oYCMpncCzGgKIEl8RmGUl/Ja6ZCR7S1HVelT29RsLba16APcHngBPuvoLy5P3dCm2f
         NBMJqruVRyZGZlzB5avooeJrx0CTaAHr/7DOVIPHbpC8lQSzOQGHa4cfRA472ZjYMjHL
         ApXJ/6BdXUvDYZI1MMbxmXLbzRR8PIIH44G2o=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=wniPomHi9VEYSjk90wl5e6CPChlLwQF50OKpUaml/b5X9+1VGMnfgmQN0nKzQne/yN
         adXxw497UJppPiynoplHffXJeerSTSfRVK5JBpEsADTYk/vlA6cH+kRGm5JbfU4aFsOT
         mcIeRVFs6YXxOlrulcHMBX51ub2OooDe9KeU8=
MIME-Version: 1.0
Received: by 10.14.127.9 with SMTP id c9mr443046eei.35.1291968085799; Fri, 10
 Dec 2010 00:01:25 -0800 (PST)
Received: by 10.14.127.71 with HTTP; Fri, 10 Dec 2010 00:01:25 -0800 (PST)
In-Reply-To: <AANLkTinWVHequQ6-6Jzj=GbT0f-M+UgyXC5=6F_TM6re@mail.gmail.com>
References: <AANLkTinAbuopWyDathERkdoJ-jK-QbNFVy-0SgrPbqh9@mail.gmail.com>
	<AANLkTinWVHequQ6-6Jzj=GbT0f-M+UgyXC5=6F_TM6re@mail.gmail.com>
Date: Fri, 10 Dec 2010 16:01:25 +0800
Message-ID: <AANLkTinSW97+rF5gxWt+v407tAO7c92zEWBjzRjhabw9@mail.gmail.com>
Subject: Re: need for more conditional write support
From: Qian Ye <yeqian.zju@gmail.com>
To: user@zookeeper.apache.org
Cc: zookeeper-user <zookeeper-user@hadoop.apache.org>,
 zookeeper-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=90e6ba5bba61d0b3e8049709c26b

--90e6ba5bba61d0b3e8049709c26b
Content-Type: text/plain; charset=UTF-8

Hi Ted:

The solution you mentioned works in some situation, but not mine. Because,
in the third step, after you checking the condition on B and C, the value on
B and C still might be modified before you update value on A. The key point
is that with the current ZK primitives, you cannot lock node A when u are
updating node B.

A possible solution based on current ZK primitives for this scenario is that
create a extra node for each data node to play as the lock. So the update on
A can be protected by this kind of lock. However, this implementation will
bring in much complexity. For example, how to prevent deadlock in some
abnormal situations.

What's more, I think this kind of conditional write support is simpler than
multiple transactions. Multiple transactions can be built with this kind of
support. The link is broken?
http://www.mail-archive.com/zookeeper-dev@hadoop.apache.org/msg08315.html


On Fri, Dec 10, 2010 at 7:33 AM, Ted Dunning <ted.dunning@gmail.com> wrote:

> Qian,
>
> Depending on your situation, you can implement something like this now with
> the ZK primitives.
>
> In particular,
>
>    - get the current version v_a of A
>    - test the values of B and C
>    - if the condition on B and C is met, update A with required version v_a
>
> You may want to retry the whole thing if you get an exception on the update
> of A.
>
> This does a safe test and set operation, but does not allow for the
> potential of atomically updating multiple znodes in one operation.  A
> special case solution to that is to put all objects that may need to be
> updated together in the same znode content.  That is clearly not a general
> solution, but it is often possible.
>
> On Thu, Dec 9, 2010 at 4:19 AM, Qian Ye <yeqian.zju@gmail.com> wrote:
>
> > Hi all:
> >
> > I'm working on a distributed system these days, and need more conditional
> > write support on Zookeeper. Now the zookeeper only support modifing,
> delete
> > or set, node data with a version number represent the current version of
> > the
> > node. I need modification on the condition of other nodes. For e.g. I
> want
> > to set the node data of /node to A, if the node data of /node1 is B and
> the
> > node data of /node2 is C. Should we support this kind of interface?
> >
> > thanks
> > --
> > With Regards!
> >
> > Ye, Qian
> >
>



-- 
With Regards!

Ye, Qian

--90e6ba5bba61d0b3e8049709c26b--