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 >> > >
