daidong 2011-04-20, 09:37
Alexander Shraer 2011-04-20, 18:29
Benjamin Reed 2011-04-20, 20:26
André Oriani 2011-04-20, 23:20
daidong 2011-04-21, 06:33
daidong 2011-04-21, 06:35
-Re: Problems about Zab protocol
Flavio Junqueira 2011-04-21, 07:48
Daidong, The comment in the paper just refers to the communication
pattern, which resembles 2PC and exists in many other replication
protocols. Let me make it clear that it was not our intention to say
that we are implementing state-machine replication with 2PC, which is
possibly the source of the confusion.
On Apr 21, 2011, at 8:35 AM, daidong wrote:
> This is the idea i can not get :)
> Why do not have aborts can simplify 2PC without any affects on
> Sent with Sparrow
> On 2011年4月21日星期四 at 上午4:26, Benjamin Reed-3 [via
> zookeeper-user] wrote:
>> just to add a bit to alex's reponse: we do a simplified 2pc since we
>> do not have aborts. we also differ from 2pc during recovery which is
>> made up of two sub phases.
>> On Wed, Apr 20, 2011 at 11:29 AM, Alexander Shraer
>> <[hidden email]> wrote:
>>> Regarding your first question - ZAB has two parts - the broadcast
>>> protocol you mention,
>>> which is executed by a leader, and the leader election protocol,
>>> which recovers from a leader failure.
>>> This is similar to the way other state-machine replication
>>> algorithms work, where you have
>>> a fast normal mode and a slower recovery mode (you don't need to
>>> execute both all the time - only when the leader fails).
>>> See Paxos state-machine replication for example (section 3): http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#paxos-simple
>>> Regarding your second question - Zookeeper basically guarantees so
>>> called "sequential consistency" semantics.
>>> This guarantees that the real execution looks to clients like some
>>> sequential execution in which
>>> the operations of every client appear in the order they were
>>> submitted. It does not guarantee that a read of one client
>>> returns the latest value written by another client. This allows
>>> reads to be executed locally. If you need to return the latest
>>> state, you can use the sync() call which flushes the pending
>>> updates between the leader and a follower.
>>> See also the "consistency guarantees" section here:
>>>> -----Original Message-----
>>>> From: daidong [mailto:[hidden email]]
>>>> Sent: Wednesday, April 20, 2011 2:38 AM
>>>> To: [hidden email]
>>>> Subject: Problems about Zab protocol
>>>> Hi, everyone.
>>>> Recently, i read the paper "a simple total ordered broadcast
>>>> there are some problems i can not figure out. Hope anyone can help
>>>> me... :P
>>>> The paper describes the Zab protocol as a 2 phase commit protocol
>>>> system is under broadcast mode. However some paper(Skeen 82, "A
>>>> Commit Protocol") has mentioned if we want to extend an 2PC to
>>>> adapt a
>>>> quorum based commit protocol we must introduce a three phase commit
>>>> protocol(In fact, i haven't quit understood this, :( ). However
>>>> Zab paper, this still can be done. Why and how to do this?
>>>> Secondly, even Zookeeper can guarantee that status in different
>>>> are consistent. However, this consistency only works among a
>>>> quorum of
>>>> followers that has acked the COMMIT. As the client can connect to
>>>> followers when perform reading action, so what happens if the
>>>> to connect with the follower that has not acked the COMMIT? I can
>>>> the information in this paper...
>>>> If i ask some naive question, Hope anybody can tell me where i
>>>> can find
>>>> answer or some suggestions, thanks :)
>>>> View this message in context: http://zookeeper-
>>>> Sent from the zookeeper-user mailing list archive at Nabble.com.
>> If you reply to this email, your message will be added to the
direct +34 93-183-8828
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300 fax (408) 349 3301
daidong 2011-04-21, 06:30
Alexander Shraer 2011-04-21, 19:53
daidong 2011-04-23, 04:55
Flavio Junqueira 2011-04-25, 07:52