It doesn't guarantee client order across sessions. When a client holding a valid session connects to a different server, we check that the server has a state at least as recent as the one it has observed before reconnecting. If the client instead creates a new session, we don't perform that check so it could end up connecting to a server that is a bit behind and consequently miss a previous successful write.
-Flavio On 15 Nov 2014, at 09:21, Ivan Kelly <[email protected]> wrote: > I'm not 100% sure, but i think session creation creates a znode > (session info is definitely passed around the quorum). Since it has to > create a znode, it will not response to the client until it sees the > znode has been created, which means it is up to date with the leader > until at least that point, so it will be able to see any updates from > the previous session. > > -Ivan > > On 14 November 2014 03:42, [email protected] <[email protected]> wrote: >> Hi, >> >> Consider the following scenario: >> >> ABCDE is the zookeeper ensemble, ABC form the quorum. >> The following sequence may happen: >> 1. Client writes the data, and ABC are updated, but DE haven't because of >> the network latency(say, long enough for this scenario). >> 2. Client closes the session. >> 3. Client start a new session in the same thread, Is zookeeper guarantee the >> client to see the previously data set in the above step(that is, it will >> connect to A, B or C) or zookeeper does NOT guarantee this(that is,it may >> connect to D or E which doesn't have the data set in above steps) >> >> I guess that Zookeeper doesn't guarantee the client to see the data set in >> the first step because the two sessions are totally different ones to >> Zookeeper even they are created by the same thread, and also because when >> the session is first created, there is no zxid information that the server >> can be used to determine the client status. >> Please correct me if I am wrong, thanks. >> >> >> >> >> [email protected]
