OK, I see. So you meant that the older ballot will not only reject in round-trip1 (prepare/promise), it also can be reject in propose/accept round-trips2, Is that correct?
You Said : Or more precisely, you got step 8 wrong: when a replica PROMISE, the promise is not that they won't "promise" a ballot older than 2,it's that they won't "accept" a ballot older than 2 Why step 8 wrong? I think replicas can accept any highest ballot, so ballot 2 is the highest in step 8? what do you think? Do you also mean replica can promise older ballot. I wish you could make it more clear. Thank you a lot Sylvain Ibrahim On Tue, Aug 25, 2015 at 1:40 PM, Sylvain Lebresne <sylv...@datastax.com> wrote: > That scenario cannot happen. More specifically, your step 12 cannot happen > if > step 8 has happen. Or more precisely, you got step 8 wrong: when a replica > PROMISE, the promise is not that they won't "promise" a ballot older than > 2, > it's that they won't "accept" a ballot older than 2. Therefore, after step > 8, > the accept from N1 will be reject in step 12 and the insert from N1 will be > rejected (that is, N1 will restart the whole algorithm with a new ballot). > > > On Tue, Aug 25, 2015 at 1:54 PM, ibrahim El-sanosi < > ibrahimsaba...@gmail.com> wrote: > >> Hi folks, >> >> >> Cassandra provides *linearizable consistency (CAS, Compare-and-Set) by >> using Paxos 4 round-trips as following* >> >> *1. **Prepare/promise* >> >> *2. **Read/result* >> >> *3. **Propose/accept* >> >> *4. **Commit/acknowledgment * >> >> Assume we have an application for resistering new account, I want to make >> sure I only allow exactly one user to claim a given account. For example, >> we do not allow two users having the same username. >> >> Assuming we have a cluster consist of 5 nodes N1, N2, N3, N4, and N5. We >> have two concurrent clients C1 and C2. We have replication factor 3 and the >> partitioner has determined the primary and the replicas nodes of the INSERT >> example are N3, N4, and N5. >> >> >> The scenario happens in following order: >> >> 1. C1 connects to coordinator N1 and sends INSERT V1 (assume V1 is >> username, not resister before) >> >> 2. N1 sends PREPARE message with ballot 1 (highest ballot have >> seen) to N3, N4 and N5. Note that this prepare for C1 and V1. >> >> 3. N3, N4 and N5 send a PROMISE message to N1, to not promise any >> with older than ballot 1. >> >> 4. N1 sends READ message to N3, N4 and N5 to read V1. >> >> 5. N3, N4 and N5 send RESULT message to N1, informing that V1 not >> exist which results in N1 will go forward to next round. >> >> 6. Now C2 connects to coordinator N2 and sends INSERT V1. >> >> 7. N2 sends PREPARE message with ballot 2 (highest ballot after >> re-prepare because first time, N2 does not know about ballot 1, then >> eventual it solves and have ballot 2) to N3, N4 and N5. Note that this >> prepare for C2 and V1. >> >> 8. N3, N4 and N5 send a PROMISE message to N2, to not promise any >> with older than ballot 2. >> >> 9. N2 sends READ message to N3, N4 and N5 to read V1. >> >> 10. N3, N4 and N5 send RESULT message to N2, informing that V1 not >> exist which results in N2 will go forward to next round. >> >> 11. Now N1 send PROPOSE message to N3, N4 and N5 (ballot 1, V1). >> >> 12. N3, N4 and N5 send ACCEPT message to N1. >> >> 13. N2 send PROPOSE message to N3, N4 and N5 (ballot 2, V1). >> >> 14. N3, N4 and N5 send ACCEPT message to N2. >> >> 15. N1 send COMMIT message to N3, N4 and N5 (ballot 1). >> >> 16. N3, N4 and N5 send ACK message to N1. >> >> 17. N2 send COMMIT message to N3, N4 and N5 (ballot 2). >> >> 18. N3, N4 and N5 send ACK message to N2. >> >> >> As result, both V1 from client C1 and V1 from client C2 have written to >> replicas N3, N4, and N5. Which I think it does not achieve the goal of >> *linearizable >> consistency and CAS. * >> >> >> >> *Is that true and such scenario could be occurred?* >> >> >> >> I look forward to hearing from you. >> >> >> Regards, >> > >
