Hello Abraham right, exactly.
my confusion is that the client FIFO order is for a client or only for a tcp connection ---------------------------------------- Github: https://github.com/baotiao Blog: http://baotiao.github.io/ Stackoverflow: http://stackoverflow.com/users/634415/baotiao Linkedin: http://www.linkedin.com/profile/view?id=145231990 > On 14 Nov 2017, at 08:12, Abraham Fine <af...@apache.org> wrote: > > Hello- > > My understanding is that the question is about the possibility of a race > condition between two client requests. I would take a look at the > section "Order in the Presence of Connection Loss" in the "ZooKeeper: > Distributed Process Coordination" book for the best answer to this > question. > > Thanks, > Abe > > On Mon, Nov 13, 2017, at 06:17, Andor Molnar wrote: >> Hi baotiao, >> >> First, requests are acknowledged back to the client once the leader >> accepted and written them in its transaction log, which guarantees that >> in >> case of a crash, pending transactions can be processed on restart. >> Transactions IDs (zxid) are incremental and generated by the leader. >> Second, Zab guarantees that if the leader broadcast T and T' in that >> order, >> each server must commit T before committing T'. >> >> With these 2 promises, I believe, that FIFO is guaranteed by Zookeeper. >> >> Would you please clarify that what do you mean by "set b=1 operation is >> on >> the way"? >> >> If "set b=1" is accepted by the leader, the client won't have to resend >> it >> on reconnect. >> >> Regards, >> Andor >> >> >> On Mon, Nov 13, 2017 at 5:01 AM, 陈宗志 <baot...@gmail.com> wrote: >> >>> I want to know in the following situation, how zookeeper promise client >>> FIFO order. >>> >>> the client sent three operation to server, set a = 1, set b = 1, set ready >>> = true. >>> >>> is it possible to this situation that the set a = 1 is process by the >>> leader, then there is something wrong with this tcp connection, this client >>> reconnect a new tcp connection to the leader, but the set b = 1 operation >>> is on the way. then the client will use the new tcp connection to sent set >>> ready = true operation. so the set a = 1 is operated, set b = 1 is not and >>> set ready = true is operated too. >>> >>> the question is how zab promise client FIFO order? >>> >>> zab can resend all the operation that hasn't be replied from the leader. >>> then in this situation, when the client reconnect to the leader, it will >>> resent the operation set b = 1, set ready = true. >>> >>> is this the way the zab used to primise FIFO order? >>> >>> Thank you all >>> >>> -- >>> --- >>> Blog: http://www.chenzongzhi.info >>> Twitter: https://twitter.com/baotiao <https://twitter.com/#%21/baotiao> >>> Git: https://github.com/baotiao >>>
