Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> zookeeper client session write-read consistency


Copy link to this message
-
Re: zookeeper client session write-read consistency
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 <
[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> > 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
>>
>
>