> Sorry if a few comments were a bit "editorial" in the first message
Not a problem at all – more than happy to talk about suggestions in that vein! Just probably best not to subject everyone else to the discussion. > What I would like to understand better and without guessing is, what do these > transactions look like from a client/user point of view? This is a fair question, and perhaps something I should pinpoint more directly for the reader. The CEP does stipulate non-interactive transactions, i.e. those that are one-shot. The only other limitation is that the partition keys must be known upfront, however I expect we will follow-up soon after with some weaker semantics that build on top (probably using optimistic concurrency control) to support transactions where only some partition keys are known upfront, so that we may support global secondary indexes with proper isolation and consistency. > whether I should just* think of this as "better and more efficient LWT” So, the LWT concept is a Cassandra one and doesn’t have an agreed-upon definition. My understanding of a core feature/limitation of LWTs is that they operate over a single partition, and as a result many operations are impossible even in multiple rounds without complex distributed state machines. The core improvement here, besides improved performance, is that we will be able to operate over any set of keys at-once. How this facility is evolved into user-facing capabilities is an open-ended question. Initially of course we will at least support the same syntax but remove the restriction on operating over a single partition. I haven’t thought about this much, as the CEP is primarily for enabling works, but I think we will want to expand the syntax in two ways: 1) to support more complex conditions (simple AND conditions across all partitions seem likely too restrictive, though they might make sense for the single partition case); 2) to support inserting data from one row into another, potentially with transformations being applied (including via UDFs). These are both relatively manageable improvements that we might want to land in the same major release as the transactions themselves. The core facility can be expanded quite broadly, though. It would be possible for instance to support some interpreted language(s) as part of a query, so that arbitrary work can be applied in the transaction. Or, perhaps the community would rather build atop the feature to support interactive transactions at the client. I can’t predict resourcing for this, though, and it might be a community effort. I think it would be quite tractable once this work lands, however. > Suppose I wanted to do a long running read-only transaction So, there’s two sides to this: with and without paging. A long running read-only transaction taking a few seconds is quite likely to be fine and we will probably support with some MVCC within the transaction system itself. This may or may not be part of v1, it’s hard to predict with certainty as this is going to be a large undertaking. But for paged queries we’d be talking about SNAPSHOT isolation. This is likely to be something the community wants to support before long anyway and is probably not as hard as you might think. It is probably outside of the scope of this work, though the two would dovetail very nicely. From: Henrik Ingo <henrik.i...@datastax.com> Date: Tuesday, 7 September 2021 at 09:24 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Tue, Sep 7, 2021 at 1:31 AM bened...@apache.org <bened...@apache.org> wrote: > > Of course, but we may have to be selective in our back-and-forth. We can > always take some discussion off-list to keep it manageable. > > I'll try to converge.Sorry if a few comments were a bit "editorial" in the first message. I find that sometimes it pays off to also ask the dumb questions, as long as we don't get stuck on any of them. > > The algorithm is hard to read since you omit the roles of the > participants. > > Thanks. I will consider how I might make it clearer that the portions of > the algorithm that execute on receipt of messages that may only be received > by replicas, are indeed executed by those replicas. > > In fact the same algorithm in the CEP was easier to read exactly because of this, I now realize. > > So I guess my question is how and when reads happen? > > I think this is reasonably well specified in the protocol and, since it’s > unclear what you’ve found confusing, I don’t know it would be productive to > try to explain it again here on list. You can look at the prototype, if > Java is easier for you to parse, as it is of course fully specified there > with no ambiguity. Or we can discuss off list, or perhaps on the community > slack channel. > > Maybe my question was a bit too open ended, as I didn't want to lead into any specific direction. I can of course tell where reads happen in the execution algorithm. What I would like to understand better and without guessing is, what do these transactions look like from a client/user point of view? You already confirmed that interactive transactions aren't intended by this proposal. At the other end of the spectrum, given that this is a Cassandra Enhancement Proposal, and the CEP does in fact state this, it seems like providing equivalent functionality to already existing LWT is a goal. So my question is whether I should just* think of this as "better and more efficient LWT" or is there something more? Would this CEP or follow-up work introduce any new CQL syntax, for example? To give just one more example of the kind of questions I'm triangulating at: Suppose I wanted to do a long running read-only transaction, such as querying a secondary index. Like SERIAL in current Cassandra, but taking seconds to execute and returning thousands of rows. How would you see the possibilities and limits of such operations in Accord? *) Should emphasize that better scaling LWTs isn't just "just". If I imagine a future Cassandra cluster where all reads and writes are transactional and therefore strict serializeable, that would be quite a change from today. henrik
