... but of course, you can disable local sessions and get the old behavior.
-Flavio On 15 Nov 2014, at 15:33, Flavio Junqueira <[email protected]> wrote: > Yeah, that's a good point. Previously we had all create session requests > committed by the leader, which implies that the session creation is totally > ordered with all other requests that update the state. However, with local > sessions, this no longer holds. > > Also, I find the notion of "consecutive sessions" a bit tricky as in the > subject of the e-mail. Does it mean that the first session has been confirmed > closed or expired before the second one was created? In any case, it is not a > promise we make that client order is respected across sessions, but certainly > reasoning in the way you stated sounds right to me. > > -Flavio > > On 15 Nov 2014, at 12:06, Ivan Kelly <[email protected]> wrote: > >> @Flavio, but doesn't a new session have to persist something in the >> state? If so, anything before this write will be visible to the >> session. >> >> On 15 November 2014 11:47, Todd <[email protected]> wrote: >>> >>> Thanks Flavio and Ivan for the reply, i understood now, thank you. >>> >>> >>> At 2014-11-15 18:26:55, "Flavio Junqueira" <[email protected]> >>> wrote: >>>> 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] >>>> >
