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: local policy)
From: Adrian Osullivan <adrian.osullivan@db.com>
To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>
Date: Tue, 5 Nov 2013 13:31:45 -0600
Subject: Sync question
Thread-Topic: Sync question
Thread-Index: Ac7aXaf6LBaPTxvlRGmw5MC3GluQtQ==
Message-ID: 
 <E0699BDD1C95EC4190CF27C12C6D72DD0102DE75500D@USTLCDBG001.US.DB.COM>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_E0699BDD1C95EC4190CF27C12C6D72DD0102DE75500DUSTLCDBG001_"
MIME-Version: 1.0

--_000_E0699BDD1C95EC4190CF27C12C6D72DD0102DE75500DUSTLCDBG001_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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 cli=
ent may have sent an update and the server one is connected to may again la=
g the leader.  So it seems there is no mechanism is zookeeper for guarantee=
ing 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 communicati=
on. 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 cont=
ained in this communication should not be regarded as such.

--_000_E0699BDD1C95EC4190CF27C12C6D72DD0102DE75500DUSTLCDBG001_--