Re: Tradeoffs for Cassandra transaction management

Hi All, First off, thank you for the very interesting technical discussions on this topic. It's been great to see some back and forth on it. I haven't been involved mainly because my research on this topic is relatively stale. I did however want to chime in to encourage us to step back and take a

Re: Tradeoffs for Cassandra transaction management

On 10/14/21 6:54 AM, Jonathan Ellis wrote: > I think I've also been clear that I want a path to supporting (1) local > latencies (SLOG is a more elegant solution but "let's just let people give > up global serializability like LWT" is also reasonable) and (2) SQL with > interactive transactions.

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 nb 2. +1 nb 3. +1 nb I am excited to see a real proposal backed by a number of competent engineers that will meaningfully improve our ability to deliver important and complex features for Cassandra. To be frank, I'm somewhat confused as to the dissent on the CEP strategy itself (tactical

Re: [VOTE] CEP-15: General Purpose Transactions

On 10/14/21 2:07 PM, Mick Semb Wever wrote: > 1. -1 > > There's discussions still ongoing around this CEP. I support the CEP but > believe it is important that the community takes the patience to let > everyone say their piece and feel that they have been heard. I do not see > that waiting a

Re: [VOTE] CEP-15: General Purpose Transactions

On Thu, Oct 14, 2021 at 11:32 AM bened...@apache.org wrote: > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, > as discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the transaction semantics

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 nb 2. +1 nb 3. +1 nb Very excited about the possibilities this CEP will open up. Thanks for putting this together, Benedict. On Thu, Oct 14, 2021 at 2:08 PM Mick Semb Wever wrote: > > > > 1. Do you support adopting this CEP? > > 2. Do you support the transaction semantics proposed by the

Re: [VOTE] CEP-15: General Purpose Transactions

> > 1. Do you support adopting this CEP? > 2. Do you support the transaction semantics proposed by the CEP for > Cassandra? > 3. Do you support an incremental approach to developing transactions in > Cassandra, leaving scope for future development? > 1. -1 There's discussions still ongoing

Re: Tradeoffs for Cassandra transaction management

On Thu, Oct 14, 2021 at 4:01 PM bened...@apache.org wrote: > The only TPC-C New Order transaction I recall you linking was interactive, > which as far as I am aware is not supported by Calvin. > The SQLite version I linked was interactive, but it can be implemented non-interactively, which is

Re: Tradeoffs for Cassandra transaction management

The only TPC-C New Order transaction I recall you linking was interactive, which as far as I am aware is not supported by Calvin. Are we settling on Calvin for your preferred system semantics then? As it does not support your preferred interactive transactions. To continue this discussion I

Re: Tradeoffs for Cassandra transaction management

I already linked a description of the TPC-C New Order transaction, and an implementation. This is the most-benchmarked OLTP transaction in the world. I look forward to your explanation of how Accord can handle this. Since your claim is that "[Accord] is equivalent to Calvin," please limit the

Re: [VOTE] CEP-15: General Purpose Transactions

On 10/14/21 9:31 AM, bened...@apache.org wrote: > 1. Do you support adopting this CEP? > 2. Do you support the transaction semantics proposed by the CEP for Cassandra? > 3. Do you support an incremental approach to developing transactions in > Cassandra, leaving scope for future development? +1

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 nb 2. +1 nb 3. +1 nb I am personally excited for the foundation this new work lays. Multi-partition transactions will enable many new features and I don’t think we should hold up it’s development for missing conceptual SQL support when the community hasn’t decided on going in the SQL

Re: [VOTE] CEP-15: General Purpose Transactions

+1 to all On Thu, Oct 14, 2021 at 11:57 AM C. Scott Andreas wrote: > 1. +1nb > 2. +1nb > 3. +1nb > > It’s been encouraging to follow discussion advancing potential > enhancements to this proposal on the other threads. > > I disagree that it is a good outcome for the project and the Apache >

Re: [IDEA] Read committed transaction with Accord

Thanks for clarifying Jonathan. I agree with your example. It seems we have now moved into discussing specific requirements/semantics for an interactive transaction implementation. Which is interesting, but beyond what I will have time to think about tonight. At least off the top of my head I

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1nb 2. +1nb 3. +1nb It’s been encouraging to follow discussion advancing potential enhancements to this proposal on the other threads. I disagree that it is a good outcome for the project and the Apache Cassandra user community to veto significant progress in this area on grounds that the

Re: [VOTE] CEP-15: General Purpose Transactions

+1 on all points > On 14 Oct 2021, at 17:31, bened...@apache.org wrote: > > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, as > discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the transaction

Re: Tradeoffs for Cassandra transaction management

> Calvin supports arbitrarily complex transactions (included dependent > statements and indexed reads and writes), executed in parallel, with locking > as necessary to enable that parallelism. By CAS I mean to include any arbitrary state mapping function for the involved keys. This is

Re: [VOTE] CEP-15: General Purpose Transactions

> Point of order I would like to encourage everyone to vote to collect the community’s views. Jonathan has vetoed the CEP, but everyone’s views are important to register and the second two votes are not on the CEP itself so remain valid. Ultimately the PMC makes all decisions, and so can

Re: [VOTE] CEP-15: General Purpose Transactions

My votes: 1. -1 for a minor and a major reason. The minor reason is that I believe we reached consensus in the discussion that allowing the equivalent of LOCAL_SERIAL should be part of the CEP, but the CEP has not been updated to reflect this. The major reason is that there is not a clear path

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 2. +1 3. +1 On Thu, Oct 14, 2021 at 6:31 PM bened...@apache.org wrote: > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, > as discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the transaction

Re: [VOTE] CEP-15: General Purpose Transactions

Point of order: our project governance states , "Once the proposal is finalized and any major committer dissent reconciled, call a [VOTE] on the ML to have the proposal adopted. The criteria for acceptance is

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 2. +1 nb 3. +1 nb nb on 2. and 3. as I am not pmc (if I got this voting logic right) On Thu, 14 Oct 2021 at 18:36, Blake Eggleston wrote: > > 1. +1 > 2. +1 > 3. +1 > > > On Oct 14, 2021, at 9:31 AM, bened...@apache.org wrote: > > > > Hi everyone, > > > > I would like to start a vote on

Re: [IDEA] Read committed transaction with Accord

... which is a long way of saying, in postgresql those errors are there as part of checking for correctness -- when you see them it means you did not ask for the appropriate locks. It's not expected that you should write try/catch/retry loops to work around this. On Thu, Oct 14, 2021 at 11:13 AM

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 2. +1 3. +1 > On Oct 14, 2021, at 9:31 AM, bened...@apache.org wrote: > > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, as > discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the

[VOTE] CEP-15: General Purpose Transactions

Hi everyone, I would like to start a vote on this CEP, split into three sub-decisions, as discussion has been circular for some time. 1. Do you support adopting this CEP? 2. Do you support the transaction semantics proposed by the CEP for Cassandra? 3. Do you support an incremental approach to

Re: Tradeoffs for Cassandra transaction management

Hi Jonathan, This conversation has been circular for some time. I think it is time to separate out your reasons for blocking progress on the CEP as part of a vote, so that the PMC may express its view on this justification for preventing the CEP’s adoption. From: Jonathan Ellis Date:

Re: [IDEA] Read committed transaction with Accord

[Moving followup here from the other thread] I think there is in fact a difference here. Consider a workload consisting of two clients. One of them is submitting a stream of TPC-C new order transactions (new order client = NOC), and the other is performing a simple increment of district next

Re: Tradeoffs for Cassandra transaction management

Do I read this email as "Jonathan will vote against any improvement to transactions that doesn't guarantee local latencies and interactive SQL, even though no such proposal exists, thereby blocking any improvement over the current status quo?" On Thu, Oct 14, 2021 at 6:55 AM Jonathan Ellis

Re: [VOTE] CEP-16 - Auth Plugin Support for CQLSH

The vote passed with 6 binding +1's and no -1's Thanks everybody. On Mon, 11 Oct 2021 at 23:34, Michael Shuler wrote: > > +1 > > On 10/11/21 4:47 AM, Stefan Miklosovic wrote: > > Hi list, > > > > based on the discussion thread about CEP-16 (1), I would like to have > > a vote on that. > > > >

Re: Tradeoffs for Cassandra transaction management

Hi Benedict, I'm not sure how to reconcile your statement that "your request to separate consensus from execution is [nonsensical]" with your earlier claims that we could build whatever additional transactional semantics we want on top of Accord. The Accord whitepaper specifically separates out