zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From German Blanco <german.blanco.bla...@gmail.com>
Subject Re: zookeeper client session write-read consistency
Date Wed, 20 Nov 2013 07:09:21 GMT
I for got one "within a session" in the previous text ...
... This means that if a client sends a write *within a session*, AND no
other client modifies that information, it will always see the result of
that write in any subsequent read ...

On Wed, Nov 20, 2013 at 8:01 AM, German Blanco <
german.blanco.blanco@gmail.com> wrote:

> 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án.
> 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
>> guarantees.
>> 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
>> that
>> approved of an update (and the server serving the read has not yet
>> received
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message