Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of german.blanco.blanco@gmail.com
 designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMs5at7UeVWPFTF3eyA=_SMiEBdarDQ+-Zdcsb1e2PREVthsRg@mail.gmail.com>
References: 
 <CAMs5at7UeVWPFTF3eyA=_SMiEBdarDQ+-Zdcsb1e2PREVthsRg@mail.gmail.com>
Date: Wed, 20 Nov 2013 08:01:41 +0100
Message-ID: 
 <CAEH-zfpaTGtq=APjPz+vmhk4Mq0TVTu_+SJ1poNcTKP2z2OHdw@mail.gmail.com>
Subject: Re: zookeeper client session write-read consistency
From: German Blanco <german.blanco.blanco@gmail.com>
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=047d7bb03e786bfb0b04eb965a71

--047d7bb03e786bfb0b04eb965a71
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hello,

I believe that if you observe that, you should try to reproduce it
with TRACE logging level and open a JIRA with the case sending the logs.
If I am not wrong, ZooKeeper transactions are guaranteed to be executed in
sequential order in all servers and within the client session. This means
that if a client sends a write, AND no other client modifies that
information, it will always see the result of that write in any subsequent
read.
This is true regardless of whether the client connects to one single server
or needs to reconnect to another server of the quorum. The session may be
kept when reconnecting, but the server checks that the last zxid seen by
the client has also been seen by the server before allowing the connection.
That means that if the client has made a write within that session, the
server will only allow the connection if the write is included in the
server's transaction log.
As you say, reads are not necessarily consistent, but that applies only to
different sessions connected to different servers.
This is at least my view on your issue.
/Germ=E1n.


On Tue, Nov 19, 2013 at 9:51 PM, Mohammad Shamma
<mohammadshamma@gmail.com>wrote:

> I have a question about the consistency guarantees of zookeeper.
>
> As far as I understand, zookeeper provides eventual consistency guarantee=
s.
> Updates are not guaranteed to be seen by read operations following an
> update (reads are not necessarily consistent). The reason behind this is
> that reads might be served by a server that was not part of the quorum th=
at
> approved of an update (and the server serving the read has not yet receiv=
ed
> the update).
>
> I have observed such write/read inconsistencies on operations within the
> same client session. Is this behavior expected? This write/read
> inconsistency is expected when the read and write are dispatched to
> different servers, however it seems a bit odd that writes and reads that
> are dispatched against the same server would be inconsistent.
>
> --
> Mohammad Shamma
>

--047d7bb03e786bfb0b04eb965a71--