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 rakeshr@huawei.com designates
 119.145.14.65 as permitted sender)
From: Rakesh R <rakeshr@huawei.com>
To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>
CC: "zookeeper-user@hadoop.apache.org" <zookeeper-user@hadoop.apache.org>
Subject: RE: Consistency in zookeeper
Thread-Topic: Consistency in zookeeper
Thread-Index: 
 AQHOFgxX9791ebmg4k+PxAzFSvapjZiPai2AgADfG2eAAE7RAIAACEiAgAAmDwCAAAQ9AIAAB4+AgAAF44CAAAM7gIAAAzuAgABDkwCAApQD6g==
Date: Sun, 3 Mar 2013 09:51:39 +0000
Message-ID: 
 <C2496325850AA74C92AAF83AA9662D26317D9417@szxeml561-mbx.china.huawei.com>
References: <1362094516049-7578531.post@n2.nabble.com>
 <CANcXBFNeFYT0FAN37Nj3H5Pkrpo8zLoyiOGPns4OGaKZkwRGdg@mail.gmail.com>
 <C2496325850AA74C92AAF83AA9662D26317D557C@szxeml561-mbx.china.huawei.com>
 <CABaj-QZUAjXzd2PKxd0Vx1=BJ2g17j6V033yw-8jGkunx2tepQ@mail.gmail.com>
 <CANcXBFOJ_s+GwLoBNGkPuL226sLMa0EnA9COX9xWHhjy-jYLkQ@mail.gmail.com>
 <FC34DAE6-7E3C-4EB9-A428-F609C50422F4@yahoo.com>
 <1362171044682-7578540.post@n2.nabble.com>
 <CABaj-QY0aW3eLMT3ZqNy25RF26609ccx+FJGtNgpU416zGUYsQ@mail.gmail.com>
 <1362173931985-7578542.post@n2.nabble.com>
 <CAP1VaJsd2fqmUhE4LqjSiRWAvkndT_LRguL2kP_bg3fO4uRWoA@mail.gmail.com>
 <5AE3EED8-8E68-455C-96CA-C5EB11E3CA58@jordanzimmerman.com>,<CAJwFCa0Hoekc14Zy6i0LyLj=eraF8JimqMZadohoKQJNTMtYSg@mail.gmail.com>
In-Reply-To: 
 <CAJwFCa0Hoekc14Zy6i0LyLj=eraF8JimqMZadohoKQJNTMtYSg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

sync() guarantees that it will synchronize the data between the zk servers =
at 't' th time.

Say we have two clients and both are working on the same key path:

First client C1, is updating the value of x at 't1', 't2' and 't3' as follo=
ws.
at t1 time, value of x =3D 4
at t2 time, update value of x =3D 5
at t3 time, update value of x =3D 6

Second client C2, which is doing sync() at 't2' time and invoke a read() re=
q at 't3' time.=20
(Ignoring the race condition between the updation of C1 and sync of C2, her=
e assume C1 update has happened first). Now C2 will see value of x=3D5 from=
 any of the ZK servers(Leader/Followers), but C2 is not guranteed to see va=
lue of x=3D6, as updation happened after sync() api call.

-Rakesh

________________________________________
From: Ted Dunning [ted.dunning@gmail.com]
Sent: Saturday, March 02, 2013 7:33 AM
To: user@zookeeper.apache.org
Subject: Re: Consistency in zookeeper

Yes.  Sync doesn't guarantee up to date.  It guarantees an ordering.  It
guarantees that if event A involves a ZK update and if you can guarantee
that A occurs before sync, then any read on a client C that is done after a
sync on C will see a successor state of A.

On Fri, Mar 1, 2013 at 2:01 PM, Jordan Zimmerman <jordan@jordanzimmerman.co=
m
> wrote:

> Even if you do the sync, another client can make a change before you do
> the subsequent read.
>
> -JZ
>
> On Mar 1, 2013, at 1:50 PM, Martin Kou <bitanarch@gmail.com> wrote:
>
> > Yasin,
> >
> > If the two clients are connected to two different ZooKeeper servers in
> the
> > cluster, then, yes.
> >
> > Generally, if you're worried that there may be another client working o=
n
> > the same key path, then you should sync() before reading.
> >
> > Best Regards,
> > Martin Kou
> >
> > On Fri, Mar 1, 2013 at 1:38 PM, Yasin <yasincelik27@gmail.com> wrote:
> >
> >> So, if the read request is made by some other client, it will not get
> the
> >> updated value without sync, right?
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://zookeeper-user.578899.n2.nabble.com/Consistency-in-zookeeper-tp757=
8531p7578542.html
> >> Sent from the zookeeper-user mailing list archive at Nabble.com.
> >>
>
>=