Does zookeeper guarantee read your write in consecutive sessions?

["bit1129@163.com" <bi...@163.com>]

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.




bit1129@163.com

Re: Does zookeeper guarantee read your write in consecutive sessions?

[Flavio Junqueira <fp...@yahoo.com.INVALID>]

... but of course, you can disable local sessions and get the old behavior.

-Flavio

On 15 Nov 2014, at 15:33, Flavio Junqueira <fp...@yahoo.com.INVALID> 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 <iv...@ivankelly.net> 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 <bi...@163.com> wrote:
>>> 
>>> Thanks Flavio and Ivan for the reply, i understood now, thank you.
>>> 
>>> 
>>> At 2014-11-15 18:26:55, "Flavio Junqueira" <fp...@yahoo.com.INVALID> 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 <iv...@ivankelly.net> 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, bit1129@163.com <bi...@163.com> 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.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> bit1129@163.com
>>>> 
> 

Re: Does zookeeper guarantee read your write in consecutive sessions?

[Flavio Junqueira <fp...@yahoo.com.INVALID>]

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 <iv...@ivankelly.net> 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 <bi...@163.com> wrote:
>> 
>> Thanks Flavio and Ivan for the reply, i understood now, thank you.
>> 
>> 
>> At 2014-11-15 18:26:55, "Flavio Junqueira" <fp...@yahoo.com.INVALID> 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 <iv...@ivankelly.net> 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, bit1129@163.com <bi...@163.com> 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.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> bit1129@163.com
>>> 

Re: Re: Does zookeeper guarantee read your write in consecutive sessions?

[Ivan Kelly <iv...@ivankelly.net>]

@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 <bi...@163.com> wrote:
>
> Thanks Flavio and Ivan for the reply, i understood now, thank you.
>
>
> At 2014-11-15 18:26:55, "Flavio Junqueira" <fp...@yahoo.com.INVALID> 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 <iv...@ivankelly.net> 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, bit1129@163.com <bi...@163.com> 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.
>>>>
>>>>
>>>>
>>>>
>>>> bit1129@163.com
>>

Re:Re: Does zookeeper guarantee read your write in consecutive sessions?

[Todd <bi...@163.com>]

Thanks Flavio and Ivan for the reply, i understood now, thank you.


At 2014-11-15 18:26:55, "Flavio Junqueira" <fp...@yahoo.com.INVALID> 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 <iv...@ivankelly.net> 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, bit1129@163.com <bi...@163.com> 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.
>>> 
>>> 
>>> 
>>> 
>>> bit1129@163.com
>

Re: Does zookeeper guarantee read your write in consecutive sessions?

[Flavio Junqueira <fp...@yahoo.com.INVALID>]

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 <iv...@ivankelly.net> 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, bit1129@163.com <bi...@163.com> 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.
>> 
>> 
>> 
>> 
>> bit1129@163.com

Re: Does zookeeper guarantee read your write in consecutive sessions?

[Ivan Kelly <iv...@ivankelly.net>]

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, bit1129@163.com <bi...@163.com> 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.
>
>
>
>
> bit1129@163.com