Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DC7B610282 for ; Mon, 16 Sep 2013 08:06:36 +0000 (UTC) Received: (qmail 36412 invoked by uid 500); 16 Sep 2013 08:06:30 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 36085 invoked by uid 500); 16 Sep 2013 08:06:17 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 36072 invoked by uid 99); 16 Sep 2013 08:06:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Sep 2013 08:06:13 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wt@penguintechs.org designates 209.85.128.177 as permitted sender) Received: from [209.85.128.177] (HELO mail-ve0-f177.google.com) (209.85.128.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Sep 2013 08:06:08 +0000 Received: by mail-ve0-f177.google.com with SMTP id db12so2652617veb.36 for ; Mon, 16 Sep 2013 01:05:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Yb/GRqu0Yn2OUYN0tfgj++RxVMO2jZcVf1LsHX5h71s=; b=RyNZeOcKwvXf1/KuKp2X0ienLqfS0hpiw2fj0hQ1lAB9UwPkyrMKTp9r3Tta+0dHD2 +HLwKtvRSVHvqSFWB1YJGInXGYD+5xhdLslJkwkrCiwYQ5KnlLKgEZcl6mUITUGcGIk8 4uRkL6r85xTxudUmqrjChw6sKl42F1P9zCQNF4IO8gBhJHh4HOYgqdFTJAuHn4VKJ8gG /ZrAQo76d5RabpyJPwsnKeq44Lodjzz5AdV9WANYKgplg1QhHnAZPfgJGZBXSfaEALod caH6aFqyfRoPoBm4F/NpeYJP7IKP1R6SFyXq+z0YRyJhVVGcqlxd1fKR8FSJsDIZEPur Jakw== X-Gm-Message-State: ALoCoQnconEz+2MLxDfhdExNJd6xZJm3Ciz5JL4uGp92Yrnf9tt+/36yj/ReiAoh7DoDnhD2iKNX X-Received: by 10.221.51.206 with SMTP id vj14mr25867237vcb.17.1379318746995; Mon, 16 Sep 2013 01:05:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.230.167 with HTTP; Mon, 16 Sep 2013 01:05:26 -0700 (PDT) X-Originating-IP: [2601:9:3100:7e:e88c:ed2f:11a6:26c0] In-Reply-To: <9252CEEA-4D8F-4FCA-BCB2-0947E7ADE22E@icloud.com> References: <9252CEEA-4D8F-4FCA-BCB2-0947E7ADE22E@icloud.com> From: Warren Turkal Date: Mon, 16 Sep 2013 01:05:26 -0700 Message-ID: Subject: Re: How to atomic execute getData and delete in distributed system To: ZooKeeper Users Content-Type: multipart/alternative; boundary=001a11332252f2798e04e67bab57 X-Virus-Checked: Checked by ClamAV on apache.org --001a11332252f2798e04e67bab57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I must not understand your question fully as cases (1) and (2) look very similar. It looks like you are trying to provide "atomic" access to the data in both cases. It looks like case (2) is a special case of case (1) in that only one of the processes is allowed to access the node and delete it. If my understanding above is correct, you may be able to do the following for case (1). You can make your processes coordinate by using a distributed lock (implemented using ZK) to guard access to the node. Once you have the lock, you can do whatever you want to the node without fear that others are acting on it. You can find example lock code in the ZK docso= r you could use the Curator lib to implement the lock. As for case (2), you don't need a lock since only one process is allowed to access it. You could create the node name with a pattern such that you know it should only be processed by process4. For example, you might have the following hierarchy of znodes: - /myapp - /myapp/case1nodes - /myapp/case2nodes Process4 and your other processes would know that only process4 is allowed to process nodes in /myapp/case2nodes. If you need to elect a process to be "process4", you can use ZK to implement an election (see this link for a ZK recipe). wt On Sun, Sep 15, 2013 at 10:27 PM, fengguang gong wrote: > Hi all=EF=BC=9A > when a znode is updated, there are four processes(1.2.3.4)can access the > znode. > Two cases: > (1)what i need is that there is only one process execute getData and > delete atomically. > (2)what i need is that process4 execute getData and delete atomically. > In case (1), EPHEMERAL_SEQUENTIAL will be used. > In case (2), what should i do? --001a11332252f2798e04e67bab57--