You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Adrian Osullivan <ad...@db.com> on 2013/11/05 20:31:45 UTC
Sync question
Hi everyone! The zk API's sync() method brings the server up to date with the leader. So the next client read should give the up to date value. But in the time between completing the sync and starting the read, another client may have sent an update and the server one is connected to may again lag the leader. So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
---
This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.
Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.
Re: Sync question
Posted by Alexander Shraer <sh...@gmail.com>.
The guarantee when using "sync + read" and updates is that the read
will see any update that completes before the sync starts (if the
update starts after the sync it is concurrent and may be reordered
even with ACID). ZooKeeper guarantees much more than eventual
consistency... if you're using sync it guarantees linearizability
between "sync + read" pairs and updates.
On Tue, Nov 5, 2013 at 11:38 AM, Adrian Osullivan
<ad...@db.com> wrote:
> Thanks, just wanted to confirm that. Some of the things you read about sync seem to suggest the next client read will be up to date but this is not strictly true. This isn't a fault of course, but by design.
>
> -----Original Message-----
> From: Jordan Zimmerman [mailto:jordan@jordanzimmerman.com]
> Sent: Tuesday, November 05, 2013 2:36 PM
> To: user@zookeeper.apache.org
> Subject: Re: Sync question
>
>> So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
>
> ZooKeeper is an eventually consistent system, not an ACID system. So, true.
>
> On Nov 5, 2013, at 11:31 AM, Adrian Osullivan <ad...@db.com> wrote:
>
>> Hi everyone! The zk API's sync() method brings the server up to date with the leader. So the next client read should give the up to date value. But in the time between completing the sync and starting the read, another client may have sent an update and the server one is connected to may again lag the leader. So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
>>
>> ---
>> This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.
>>
>> Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.
>
>
> ---
> This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.
>
> Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.
Re: Sync question
Posted by Benjamin Reed <br...@apache.org>.
the read will be up to date with respect to the sync: the data you read is
guaranteed to reflect at least the state of the system when the sync
executed. even if you only have one server, so it is always perfectly
up-to-date, you can do a read and the server will return the latest value,
but by the time the network packet gets to you an update could have
happened at the leader such that you are up-to-date.
the same thing happens with writes as well: you do a write, but by the time
you get the response another client may have updated your value.
if you want to get something stronger, you can surround your reads and
writes with a lock znode that must be acquired and released by clients when
reading or writing the data. this will be a large overhead for very little
gain though.
ben
On Tue, Nov 5, 2013 at 11:38 AM, Adrian Osullivan
<ad...@db.com>wrote:
> Thanks, just wanted to confirm that. Some of the things you read about
> sync seem to suggest the next client read will be up to date but this is
> not strictly true. This isn't a fault of course, but by design.
>
> -----Original Message-----
> From: Jordan Zimmerman [mailto:jordan@jordanzimmerman.com]
> Sent: Tuesday, November 05, 2013 2:36 PM
> To: user@zookeeper.apache.org
> Subject: Re: Sync question
>
> > So it seems there is no mechanism is zookeeper for guaranteeing a read
> is truly up to date with the leader. Is this true?
>
> ZooKeeper is an eventually consistent system, not an ACID system. So, true.
>
> On Nov 5, 2013, at 11:31 AM, Adrian Osullivan <ad...@db.com>
> wrote:
>
> > Hi everyone! The zk API's sync() method brings the server up to date
> with the leader. So the next client read should give the up to date value.
> But in the time between completing the sync and starting the read, another
> client may have sent an update and the server one is connected to may again
> lag the leader. So it seems there is no mechanism is zookeeper for
> guaranteeing a read is truly up to date with the leader. Is this true?
> >
> > ---
> > This communication may contain confidential and/or privileged
> information. If you are not the intended recipient (or have received this
> communication in error) please notify the sender immediately and destroy
> this communication. Any unauthorized copying, disclosure or distribution of
> the material in this communication is strictly forbidden.
> >
> > Deutsche Bank does not render legal or tax advice, and the information
> contained in this communication should not be regarded as such.
>
>
> ---
> This communication may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this communication
> in error) please notify the sender immediately and destroy this
> communication. Any unauthorized copying, disclosure or distribution of the
> material in this communication is strictly forbidden.
>
> Deutsche Bank does not render legal or tax advice, and the information
> contained in this communication should not be regarded as such.
>
RE: Sync question
Posted by Adrian Osullivan <ad...@db.com>.
Thanks, just wanted to confirm that. Some of the things you read about sync seem to suggest the next client read will be up to date but this is not strictly true. This isn't a fault of course, but by design.
-----Original Message-----
From: Jordan Zimmerman [mailto:jordan@jordanzimmerman.com]
Sent: Tuesday, November 05, 2013 2:36 PM
To: user@zookeeper.apache.org
Subject: Re: Sync question
> So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
ZooKeeper is an eventually consistent system, not an ACID system. So, true.
On Nov 5, 2013, at 11:31 AM, Adrian Osullivan <ad...@db.com> wrote:
> Hi everyone! The zk API's sync() method brings the server up to date with the leader. So the next client read should give the up to date value. But in the time between completing the sync and starting the read, another client may have sent an update and the server one is connected to may again lag the leader. So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
>
> ---
> This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.
>
> Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.
---
This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.
Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.
Re: Sync question
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
> So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
ZooKeeper is an eventually consistent system, not an ACID system. So, true.
On Nov 5, 2013, at 11:31 AM, Adrian Osullivan <ad...@db.com> wrote:
> Hi everyone! The zk API's sync() method brings the server up to date with the leader. So the next client read should give the up to date value. But in the time between completing the sync and starting the read, another client may have sent an update and the server one is connected to may again lag the leader. So it seems there is no mechanism is zookeeper for guaranteeing a read is truly up to date with the leader. Is this true?
>
> ---
> This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.
>
> Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.