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
