Did I bite someone? 😂 Thanks for your patience with all the questions and comments Benedict. I believe that everybody is pretty excited by this CEP. At least I am :-)
Le lun. 27 sept. 2021 à 22:59, bened...@apache.org <bened...@apache.org> a écrit : > Ok, it’s time for the weekly poking of the hornet’s nest. > > Any more thoughts, questions or criticisms, anyone? > > From: bened...@apache.org <bened...@apache.org> > Date: Friday, 24 September 2021 at 22:41 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > I’m not aware of anybody having taken any notes, but somebody please chime > in if I’m wrong. > > From my recollection, re Accord: > > > * Q: Will batches now support rollbacks? > * Batches would apply atomically or not, but unlikely to have a > concept of rollback. Timeouts remain unknown, but hope to have some > mechanism to provide clients a definitive answer about such transactions > after the fact. > * Q: Can stale replicas participate in transactions? > * Accord applies conflicting transactions in-order at every > replica, so only nodes that are up-to-date may participate in the execution > of a transaction, but any replica may participate in agreeing a > transaction. To ensure replicas remain up-to-date I anticipate introducing > a real-time repair facility at the transactional message level, with peers > reconciling recently processed messages and cross-delivering any that are > missing. > * Possible UX directions in very vague terms: CQL atomic and > conditional batches initially; going forwards interactive transactions? > Complex user defined functions? SQL? > * Discussed possibility of LOCAL_QUORUM reads for globally replicated > transactional tables, as this is an important use case > * Simple stale reads to transactional tables > * Brainstormed a bit about serializable reads to a single DC > without (normally) crossing WAN > * Discussed possibility of multiple ACKs providing separate LAN and > WAN persistence notifications to clients > * Discussed size of fast path quorums in Accord, and how this might > affect global latency in high RF clusters (i.e. not optimal, and in some > cases may need every DC to participate) and how this can be modified by > biasing fast path electorate so that 2 of the 3 DCs may reach fast-path > decisions with each other (remaining DC having to reach both those DCs to > reach fast path). Also discussed Calvin-like modes of operation that would > offer optimal global latency for sufficiently small clusters at RF=3 or > RF=5. > > I’m sure there were other discussions I can’t remember, perhaps others can > fill in the blanks. > > > From: Jonathan Ellis <jbel...@gmail.com> > Date: Friday, 24 September 2021 at 20:28 > To: dev <dev@cassandra.apache.org> > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > Does anyone have notes for those of us who couldn't make the call? > > On Wed, Sep 22, 2021 at 1:35 PM bened...@apache.org <bened...@apache.org> > wrote: > > > Hi everyone, > > > > Joey has helpfully arranged a call for tomorrow at 8am PST / 10am CST / > > 4pm BST to discuss Accord and other things in the community. There are no > > plans to make any kind of project decisions. Everyone is welcome to drop > in > > to discuss Accord or whatever else might be on your mind. > > > > https://gather.town/app/2UKSboSjqKXIXliE/ac2021-cass-social > > > > > > From: bened...@apache.org <bened...@apache.org> > > Date: Wednesday, 22 September 2021 at 16:22 > > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > > No, I would expect to deliver strict serializable interactive > transactions > > using Accord. These would simply corroborate that the participating keys > > had not modified their write timestamps during the final transaction. > These > > could even be undertaken with still only a single wide area round-trip, > > using local copies of the data to assemble the transaction (though this > > would marginally increase the chance of aborts) > > > > My goal for MVCC is parallelism, not additional isolation levels (though > > snapshot isolation is useful and we’ll probably also want to offer that > > eventually) > > > > From: Henrik Ingo <henrik.i...@datastax.com> > > Date: Wednesday, 22 September 2021 at 15:15 > > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > > On Wed, Sep 22, 2021 at 7:56 AM bened...@apache.org <bened...@apache.org > > > > wrote: > > > > > Could you explain why you believe this trade-off is necessary? We can > > > support full SQL just fine with Accord, and I hope that we eventually > do > > so. > > > > > > > I assume this is really referring to interactive transactions = multiple > > round trips to the client within a transaction. > > > > You mentioned previously we could later build a more MVCC like > transaction > > semantic on top of Accord. (Independent reads from a single snapshot, > > followed by a commit using Accord.) In this case I think the relevant > > discussion is whether Accord is still the optimal building block > > performance wise to do so, or whether users would then have lower > > consistency level but still pay the performance cost of a stricter > > consistency level. > > > > henrik > > -- > > > > Henrik Ingo > > > > +358 40 569 7354 <358405697354> > > > > [image: Visit us online.] <https://www.datastax.com/> [image: Visit us > on > > Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on > YouTube.] > > < > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e= > > > > > [image: Visit my LinkedIn profile.] < > https://www.linkedin.com/in/heingo/ > > > > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced >
