Unmesh, LWTs today repair themselves periodically already, and do not rely on a later proposer.
Also, the CMS will naturally use a single partition key for each log it needs to maintain, else they would not be linearised. > On 2 Sep 2022, at 05:01, Unmesh Joshi <unmeshjo...@gmail.com> wrote: > > >> 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. > > > Thanks, will follow the implementation. > >> 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. > > Yes, it's the inability of the proposer to collect a second quorum. As I > understand the existing LWT Paxos implementation is per key instance of > Paxos. Being a key-value setup, it can always repair incomplete paxos runs > when the key is read, For immutable log entries for CMS, it needs to be > different. (LWT is also expecting a mutable operation on key. So it requires > resetting of paxos state on commit and handling committed values separately > as part of prepare. For immutable entries, that's not required). But will > wait for the Jira and PR to understand the proposed approach better. > > Thanks, > Unmesh > > >> >>> 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 >>
