Flavio Paiva Junqueira commented on ZOOKEEPER-30:

Andrew, It would be really good for us to see a preliminary patch, just to have 
an idea of how you have implemented a few things.

Although perhaps not exactly appropriate, Ben and I had a discussion offline 
about having or not propose returning a zxid. Currently, only the leader 
proposes, since broadcast messages are requests transformed into idempotent 
transactions. If we follow this model, then returning a zxid is not a problem 
because the leader is the one generating a zxid and a propose call does not 
block in this case.

I understand, however, that you are interested in having Zab in such a way that 
any process in the ensemble can propose. If any process can propose, then it 
might not make sense to have a call to propose returning a zxid. The problem of 
not returning a zxid is that currently the broadcast layer and the application 
layer are tightly coupled and separating them creates a potential problem for 
generating snapshots that we use to recover or bring a new follower up to 
speed. In a little more detail, if we separate the state from the atomic 
broadcast and return no zxid, then the service layer on top of zab will have no 
such a notion of transaction identifiers. We currently use such identifiers to 
generate and guarantee a consistent state transfer. 


> Hooks for atomic broadcast protocol
> -----------------------------------
>                 Key: ZOOKEEPER-30
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-30
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: quorum
>            Reporter: Patrick Hunt
>            Assignee: Mahadev konar
> Moved from SourceForge to Apache.
> http://sourceforge.net/tracker/index.php?func=detail&aid=1938788&group_id=209147&atid=1008547

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to