----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28119/#review62233 -----------------------------------------------------------
This is good, I have a few comments in the case you want to incorporate some of those. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment55> primitive File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment56> provided File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment57> compare-and swap is more common. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment58> The term typically used to refer to a single client writing is single-writer (as opposed to multi-writer). In fact, acronyms like SWSR (single writer, single reader) or SWMR (single writer, multiple reader) are used in the literature. BK is SWMR. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment59> Since you referred to a "consistent store with CAS" above, you may want to say that you need such a store to be able to elect a leader, like ZK. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment60> "... it must read executing the following steps:" File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment61> Why 2 ledgers instead of 1? File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment62> In this fencing here the ledger-level fencing we have internally or something else? It isn't clear if the developer of an app on top of BK needs to do anything for the fencing to happen of if this text is simply explaining what happens under the hood. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment63> It would be nice to explain why we have Q_w. Q_w is the number of total replicas of a record we expect to have, but we only really wait for Q_a before responding to the application. Understood that there is more discussion about this below, but since you mention Q_a, it might be nice to mention Q_w as well for completeness. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment64> One of the great advantages of being single-writer is that we can rely on the writer to assign the entry ids. Otherwise, we would need a sequencer per ledger. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment65> Refer to the next section for an explanation of why a concurrent write to the metadata could happen. File Attachment: bk_protocol.txt - bk_protocol.txt <https://reviews.apache.org//r/28119/#fcomment66> we send an error? - fpj On Nov. 17, 2014, 2:58 p.m., Ivan Kelly wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28119/ > ----------------------------------------------------------- > > (Updated Nov. 17, 2014, 2:58 p.m.) > > > Review request for bookkeeper. > > > Description > ------- > > A high level description of the bookkeeper protocol and the guarantees we > provide. > > I'll put this into textile before submitting, but I wanted to leave it in a > more text readable format for review. > > > Diffs > ----- > > > Diff: https://reviews.apache.org/r/28119/diff/ > > > Testing > ------- > > > File Attachments > ---------------- > > bk_protocol.txt > > https://reviews.apache.org/media/uploaded/files/2014/11/17/f47f48e9-c284-4473-b4e9-584b24af7a14__bk_protocol.txt > > > Thanks, > > Ivan Kelly > >
