> making sure that joining and leaving nodes update some state via Paxos > instead of via gossip What kind of a time delivery risk does coupling CEP-15 with CEP-21 introduce (i.e. unk-unk on CEP-21 leading to delay cascades to CEP-15)? Seems like having a table we CAS state for on epochs wouldn't be *too *challenging, but I'm not familiar w/the details so I could be completely off here.
Being able to deliver both of these things on their own timetable seems like a pretty valuable thing assuming the lift required would be modest. On Fri, Mar 24, 2023, at 6:15 AM, Benedict wrote: > > Accord doesn’t have a hard dependency on CEP-21 fwiw, it just needs > linearizable epochs. This could be achieved with a much more modest patch, > essentially avoiding almost all of the insertion points of cep-21, just > making sure that joining and leaving nodes update some state via Paxos > instead of via gossip, and assign an epoch as part of the update. > > It would be preferable to use cep-21 since it introduces this functionality, > and our intention is to use cep-21 for this. But it isn’t a hard dependency. > > >> On 22 Mar 2023, at 20:58, Henrik Ingo <henrik.i...@datastax.com> wrote: >> >> Since Accord depends on transactional meta-data... is there really any >> alternative than what you propose? >> >> Sure, if there is some subset of Accord that could be merged, while work >> continues on a branched that is based on CEP-21 branch, that would be great. >> Merging even a prototype of Accord to trunk probably has marketing value. >> (Don't laugh, many popular databases have had "atomic transactions, except >> if anyone executes DDL simultaneously".) >> >> On Tue, Mar 14, 2023 at 8:39 PM Caleb Rackliffe <calebrackli...@gmail.com> >> wrote: >>> We've already talked a bit >>> <https://lists.apache.org/list?dev@cassandra.apache.org:2023-1:Merging%20CEP-15%20to%20trunk> >>> about how and when the current Accord feature branch should merge to >>> trunk. Earlier today, the cep-21-tcm branch was created >>> <https://lists.apache.org/thread/qkwnhgq02cn12jon2h565kh2gpzp9rry> to house >>> ongoing work on Transactional Metadata. >>> >>> Returning to CASSANDRA-18196 >>> <https://issues.apache.org/jira/browse/CASSANDRA-18196> (merging Accord to >>> trunk) after working on some other issues, I want to propose changing >>> direction slightly, and make sure this makes sense to everyone else. >>> >>> 1.) There are a few minor Accord test issues in progress that I'd like to >>> wrap up before doing anything, but those shouldn't take long. (See >>> CASSANDRA-18302 <https://issues.apache.org/jira/browse/CASSANDRA-18302> and >>> CASSANDRA-18320 <https://issues.apache.org/jira/browse/CASSANDRA-18320>.) >>> 2.) Accord logically depends on Transactional Metadata. >>> 3.) The new cep-21-tcm branch is going to have to be rebased to trunk on a >>> regular basis. >>> >>> So... >>> >>> 4.) I would like to pause merging cep-15-accord to trunk, and instead >>> rebase it on cep-21-tcm until such time as the latter merges to trunk, at >>> which point cep-15-accord can be rebased to trunk again and then merged >>> when ready, nominally taking up the work of CASSANDRA-18196 >>> <https://issues.apache.org/jira/browse/CASSANDRA-18196> again. >>> >>> Any objections to this? >> >> >> -- >> >> >> >> >> *Henrik Ingo* >> >> *c*. +358 40 569 7354 >> >> *w*. _www.datastax.com_ >> >> __ <https://www.facebook.com/datastax> __ <https://twitter.com/datastax> >> __ <https://www.linkedin.com/company/datastax/> __ >> <https://github.com/datastax/> >>
