| 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.
-Flavio
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 Integrity? Thanks! -- daidong 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.
ben
On Wed, Apr 20, 2011 at 11:29 AM, Alexander Shraer
<[hidden email]> wrote:
Hi,
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:
http://hadoop.apache.org/zookeeper/docs/r3.3.1/zookeeperProgrammers.html
Alex
-----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 protocol"
and
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 when
system is under broadcast mode. However some paper(Skeen 82, "A Quorum
Based
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
according
Zab paper, this still can be done. Why and how to do this?
Secondly, even Zookeeper can guarantee that status in different
followers
are consistent. However, this consistency only works among a quorum of
followers that has acked the COMMIT. As the client can connect to any
followers when perform reading action, so what happens if the client
happens
to connect with the follower that has not acked the COMMIT? I can not
find
the information in this paper...
If i ask some naive question, Hope anybody can tell me where i can find
the
answer or some suggestions, thanks :)
--
View this message in context: http://zookeeper-
user.578899.n2.nabble.com/Problems-about-Zab-protocol-
tp6290102p6290102.html
Sent from the zookeeper-user mailing list archive at Nabble.com.
If you reply to this email, your message will be added to the discussion below: http://zookeeper-user.578899.n2.nabble.com/Problems-about-Zab-protocol-tp6290102p6292118.html
To unsubscribe from Problems about Zab protocol, click here.
-- View this message in context: http://zookeeper-user.578899.n2.nabble.com/Problems-about-Zab-protocol-tp6290102p6293379.htmlSent from the zookeeper-user mailing list archive at Nabble.com.
flaviojunqueira research scientist f...@yahoo-inc.comdirect +34 93-183-8828 avinguda diagonal 177, 8th floor, barcelona, 08018, esphone (408) 349 3300 fax (408) 349 3301
 |
