Usually implementations are not documented in CEP. I think implementation has to work according to expectations described in CEP, and have enough tests to prove it. You can follow the progress of the patch whenever CEP is accepted and code is published to learn about the details.
If you'd like to learn more about incomplete Paxos writes (I'm assuming you mean dealing with inability of proposer to collect a second quorum), you can refer to Cassandra Paxos implementation. In our prototypes, we were able to simply use Cassandra Paxos out of the box, and everything related to Paxos is hidden from us behind CQL syntax. We can also have a more detailed discussion on Jira whenever the patch is posted if you feel there might be some implementation-specific aspects that should be given extra consideration. Thank you, --Alex On Thu, Sep 1, 2022, at 11:08 AM, Unmesh Joshi wrote: > On Thu, Sep 1, 2022 at 11:20 AM Alex Petrov <al...@coffeenco.de> wrote: >> __ >> There will be no changes required to our existing Paxos implementation. We >> can just use it. Besides, Paxos is only used as K-sequencer. There is no >> need to use Raft, and both existing LWTs (with Multi-Paxos) and Accord >> aren't tied to a single leader, which is well in the spirit of Cassandra. > > Will the CMS log implementation be documented in another CEP? There are > subtle things like dealing with uncommitted incomplete writes or > propagating committed log entries to all the CMS replicas while deciding how > to maintain commit-index for the log will be a good detail to add? > The LWT Paxos implementation does this for the per key instance of Paxos when > a new Paxos read/write triggered (with special handling of committed values). > > Thanks, > Unmesh
