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 devaki.vamsi@gmail.com
 designates 209.85.192.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54672442.4030400@devoteam.com>
References: <32afb2d6.237d.149b15a530e.Coremail.rchzzjcn@163.com>
 <CAD=ttqQRhRY5xpSHWNx_fAToUew71qSL0GqSAya+myjDQ83Bvw@mail.gmail.com>
 <54672442.4030400@devoteam.com>
From: Vamsi Devaki <devaki.vamsi@gmail.com>
Date: Sat, 15 Nov 2014 07:38:12 -0800
Message-ID: 
 <CAFuMMGTCAnAA0HGWSuKdsh1JX_AqH3EiAXXiZD=i9Ns+Zo5XtA@mail.gmail.com>
Subject: Re: A suggestion about the design for znode version in ZooKeeper
To: user <user@zookeeper.apache.org>
Content-Type: multipart/alternative; boundary=001a11c135e8b252460507e789dd

--001a11c135e8b252460507e789dd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Robin,

One way to work with the situation is to use multi / transaction API. You
can check the version of the parent and operate on child nodes atomically.

A quick explanation can be found at -
http://tdunning.blogspot.com/2011/06/tour-of-multi-update-for-zookeeper.htm=
l

Regards,
Vamsi


On Sat, Nov 15, 2014 at 2:00 AM, "J=C3=BCrgen Wagner (DVT)" <
juergen.wagner@devoteam.com> wrote:

>  Zookeeper uses an optimistic appoach in this case. The "problem" will
> only occur if you simply use the optimistic mode in your application as
> well.
>
> So, you have to implement a pessimistic version, i.e., create a lock and
> then perform the update or guarantee otherwise that the required operatio=
ns
> will be atomic. In that case, you can guarantee that nobody will delete t=
he
> node while you're busy with the update.
>
> Cheers,
> --J=C3=BCrgen
>
>
>
> On 15.11.2014 10:25, Ivan Kelly wrote:
>
> another option would be to start the znode id at the znode id of the
> parent znode which will be different between each deletion and
> creation of child nodes. One problem with this though (apart from
> being limited to 2^31 bits), is that the api doesn't have any way to
> return the initial znode version on creation. Fixing this, in a
> backward-compatible, non-ugly way would be hard I think.
>
> -Ivan
>
> On 15 November 2014 03:48, Robin <rchzzjcn@163.com> <rchzzjcn@163.com> wr=
ote:
>
>  Hi zookeepers,
>
> When I dig into ZooKeeper's internals, I have learned the following flaw =
about znode version in ZooKeeper: znode's version will be reset when znode =
is deleted/re-created. This is a trap for some operations which make update=
s based on znode version.
>
> Let's see an example:  a client gets the data of a znode (e.g, /test)  an=
d version(e.g, 1), change the data of the znode, and writes it back with th=
e condition that the version does not change (still be 1). If another clien=
t deletes and re-creates this znode during the first client is updating the=
 data, the version matches, but it now contains the wrong data.
>
> The problem I can see is that the znode version is designed to be a monot=
onically increasing integer. If we can include the birth-date(timestamp) of=
 the znode or zxid for the creation of the znode as part of the znode's ver=
sion, and only the integer part of the version will increase every time whe=
n the znode is updated, while keeping the birth-date or zxid part of the ve=
rsion not change, we can avoid the problem.
>
> Of course, there will be some cost for the new design: it needs bigger si=
ze for the version field.
>
> Thanks,
> - Robin
>
>
>
> --
>
> Mit freundlichen Gr=C3=BC=C3=9Fen/Kind regards/Cordialement v=C3=B4tre/At=
entamente/=D0=A1
> =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC
> *i.A. J=C3=BCrgen Wagner*
> Head of Competence Center "Intelligence"
> & Senior Cloud Consultant
>
> Devoteam GmbH, Industriestr. 3, 70565 Stuttgart, Germany
> Phone: +49 6151 868-8725, Fax: +49 711 13353-53, Mobile: +49 171 864 1543
> E-Mail: juergen.wagner@devoteam.com, URL: www.devoteam.de
> ------------------------------
> Managing Board: J=C3=BCrgen Hatzipantelis (CEO)
> Address of Record: 64331 Weiterstadt, Germany; Commercial Register:
> Amtsgericht Darmstadt HRB 6450; Tax Number: DE 172 993 071
>
>
>


--=20
Vamsi

--001a11c135e8b252460507e789dd--