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

[Marcus Eriksson]

1. +1
2. +1
3. +1

On Thu, Oct 14, 2021 at 04:31:29PM +, 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 proposed by the CEP for Cassandra?
> 3. Do you support an incremental approach to developing transactions in 
> Cassandra, leaving scope for future development?
> 
> The first vote is a consensus vote of all committers, the second and third 
> however are about project direction and therefore are simple majority votes 
> of the PMC.
> 
> Recall that all -1 votes must be accompanied by an explanation. If you reject 
> the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
> majority reject grounds (2) or (3) then transaction developments will halt 
> for the time being.
> 
> This vote will be open for 72 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Tradeoffs for Cassandra transaction management

[Jordan West]

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 look
at the topic of whether SQL support is the direction we want to be going
with Cassandra. For some context, I now work on and operate both Cassandra
and CockroachDB at a relatively large scale. In this case, CockroachDB is
not positioned as a potential replacement for Cassandra but as an
additional choice to meet different needs. Meeting those needs necessitates
different tradeoffs. Tradeoffs that have concrete impacts on how the
database performs, how production support works, how the user can break the
database, and what can be accomplished successfully by the user. When I
look at what my users need from Cassandra, it's not to have a competing
solution to CockroachDB -- a solution that exists and is becoming more and
more production proven every day. They do however need things like
scalable, consistent secondary indexing -- a feature I envision Accord
could unlock with its multi-partition CAS/transactions -- or better
performing single-partition LWTs -- ones that take significantly less round
trips and work over the WAN. I would encourage those pushing for SQL
support to consider that and to start a discussion first with the community
on whether SQL support is the direction we should be heading in the best
interest of the project.

The technical understanding I do have of both Accord and CockroachDB leads
me to believe that holding up CEP-15 for that decision, regardless of
whether we decide SQL support is the direction to go or not, is not
necessary. I believe it was stated earlier in the thread but if Accord
provides similar or better guartunees than Raft then a similar distributed
transaction protocol can be built on top of it to support interactive SQL.

Jordan


On Tue, Oct 12, 2021 at 8:21 PM Jonathan Ellis  wrote:

> Blake (and Benedict), I’ll ask for your patience here.  We don’t have a
> precedent of pushing through major initiatives in this project in a matter
> of weeks.  We [members of the PMC that weren’t involved in creating Accord]
> need time to do thorough research and make sure both that we understand
> what is being proposed and that we have evaluated reasonable alternatives.
>
> One of the difficulties in evaluating Accord is that it combines a
> state-of-the-art consensus/ordering protocol with a fairly limited
> transaction manager.  So it may be useful to decouple the consensus and
> transaction processing components, which would both allow non-Cassandra
> usage of the consensus piece, and also make explicit the boundaries with
> transaction processing with the consequence of making it easier to evolve
> independently.
>
> In the meantime, it’s very important to me to understand on which
> dimensions the transaction manager can be improved easily, and which
> dimensions resist such improvement.  I get that Accord is your [plural]
> baby and it’s awkward for me to come along and start pointing at its
> limitations, but that’s part of creating a complete understanding of any
> system.
>
> If I keep coming back to the subject of SQL support and interactive
> transactions, that’s because it’s becoming table stakes in the distributed
> database space. People are using Cockroach or Yugabyte or Cloud Spanner for
> use cases where a couple years ago they would have used Cassandra. We can
> expect this trend to continue and strengthen.
>
> On Mon, Oct 11, 2021 at 11:39 PM Blake Eggleston
>  wrote:
>
> > Let’s get back on topic.
> >
> > Jonathan, in your opening email you stated that, in your view, the 2 main
> > areas of tradeoff were:
> >
> > > 1. Is it worth giving up local latencies to get full global
> consistency?
> >
> > Now we’ve established that we don’t need to give up local latencies with
> > Accord, which leaves:
> >
> > > 2. Is it worth giving up the possibility of SQL support, to get the
> > benefits of deterministic transaction design?
> >
> > I pointed out that this was a false dilemma and that, in the worst case,
> a
> > hypothetical SQL feature could have it’s own consensus system. I hope
> that
> > won’t be necessary, but as I later pointed out (and you did not address,
> > although maybe I should have phrased it as a question), if we’re going to
> > weigh accord against a hypothetical SQL feature that lacks design goals,
> or
> > any clear ideas about how it might be implemented, how can we rule that
> out?
> >
> > So Jonathan, how can we rule that out? How can we have a productive
> > discussion about a feature you yourself are unable to describe in any
> > meaningful detail?
> >
> > > On Oct 11, 2021, at 6:34 PM, Jonathan Ellis  wrote:
> > >
> > > On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org <
> bened...@apache.org
> > >
> > > wrote:
> > >
> > >> If we want to full

Re: Tradeoffs for Cassandra transaction management

[Dinesh Joshi]

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.


99% of the transactions in a system will not be performed as interactive
SQL transactions by a human. We should be optimizing for the 99%.

Dinesh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

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

[Joseph Lynch]

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 implementation questions aside). The text
seems rather uncontroversial (~= "let's make fast general purpose
transactions") and I feel like it's rather odd to say we don't want to
at least try out an actual solution that has actual engineers with
time to work on it versus any other option where the code doesn't even
begin to exist much less full time engineers willing to spend time on
it.

Certainly this CEP meets the standard for support? It is well thought
out, well researched, a prototype exists, that prototype appears to be
well tested, and the authors significantly engaged with the community
incorporating feedback.

-Joey


On Thu, 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 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?
>
> The first vote is a consensus vote of all committers, the second and third 
> however are about project direction and therefore are simple majority votes 
> of the PMC.
>
> Recall that all -1 votes must be accompanied by an explanation. If you reject 
> the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
> majority reject grounds (2) or (3) then transaction developments will halt 
> for the time being.
>
> This vote will be open for 72 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

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

[Dinesh Joshi]

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 week, or two, before another vote risks the inclusion of
> this CEP in this release cycle. I've certainly appreciated reading through
> every question raised, and wouldn't object to the CEP page being updated to
> include even more (but this is not a blocker for me).

Taken from the project's governance[1] page -

Guiding philosophy: "Mindfully balance the need for progress with the
need for consensus"

I think the CEP as it stands with its current scope is complete.

Holding it up for forward looking features such as SQL support in
Cassandra is stopping incremental progress for something that someone
might want to contribute in the future.

Thanks,

Dinesh


[1]
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

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

[bened...@apache.org]

Mick,

With respect, I would appreciate it if you would re-read the discussion in 
full. I have been in discussion with Jonathan for a month with no progress. I 
have still not received answers to simple questions I have posed on multiple 
times over a dozen emails (see below), all of which I consider basic 
requirements for constructive engagement.

Jonathan’s expectation that I engage with every demand, coupled with his highly 
selective responses to emails and failure to respond to basic queries, has 
genuinely caused significant toll on my health and mental well-being over the 
past month. I have invested a great deal of time and energy engaging with 
everyone in the community on this CEP, but this aspect of the episode has been 
hugely dissuading to pursuing this kind of activity in future. I am unwilling 
to continue engaging with Jonathan without significant changes to his approach. 
I do not think that it is healthy either for me or the community to expect it, 
either.

I believe we need to update the CEP process to make clear what the expectations 
are on each participant, and I will explore this in the aftermath of this vote, 
whatever the outcome.

If you could help me understand what I could have done better to achieve 
constructive engagement on my below queries and points I would appreciate it, 
but perhaps we can take that offline.


- Requested specific semantic goals to contextualise discussion [2,3,6,7,8,13]

- Requested specific technical shortcomings of Accord with respect to achieving 
these goals [2,3,6,8,9,13]

- Offered a video call to discuss in detail [0,2,4,5,6,13] (an answer to 
decline was forthcoming after almost a month and only after repeated requests – 
I continue to maintain this would be a much more productive and less burdensome 
medium, but no explanation has been forthcoming for his reticence to engage 
with this)

- Discussed or reiterated Accord's compatibility with all transaction systems 
mooted by Jonathan [0,1,2,3,7,10,11,12,13]. Jonathan has evidently rejected one 
of these approaches for interactive transactions, seemingly requiring that we 
pursue a Cockroach style approach, but he is separately demanding a Calvin line 
of enquiry and has not yet engaged with my explanations of Accord’s 
compatibility with the Cockroach approach, either to ask for clarification or 
to explain my mistake.



[0] 
https://lists.apache.org/thread.html/r5656428f3d0154c008ba19b74bf26cf1518b42309bcfd770a74dab4d%40%3Cdev.cassandra.apache.org%3E

[1] 
https://lists.apache.org/thread.html/re1192924ca9f9e1a533e33c6df169c37f9c2d2bcb133e034adb6e079%40%3Cdev.cassandra.apache.org%3E

[2] 
https://lists.apache.org/thread.html/r68e08d2441b9df9e3606e0fc2adacdda638beff30543ef15b3d46a80%40%3Cdev.cassandra.apache.org%3E

[3] 
https://lists.apache.org/thread.html/r7da88e29adcce7e98d048753224fe84dea026c24632336038eea1d47%40%3Cdev.cassandra.apache.org%3E

[4] 
https://lists.apache.org/thread.html/r58cf47ff3d654807f743161a2a35cf79b30e4602afb44db50edbbb9e%40%3Cdev.cassandra.apache.org%3E

[5] 
https://lists.apache.org/thread.html/rff5425aee42e0758f86c2d53790fb5870b6fa6d6d7edcd54f93d8df1%40%3Cdev.cassandra.apache.org%3E

[6] 
https://lists.apache.org/thread.html/rf96513cfd5ddab52ecdf9d7d579ca46f9ac85cd3053c39a6e8faa332%40%3Cdev.cassandra.apache.org%3E

[7] 
https://lists.apache.org/thread.html/r394064787a9db6d02de73e5d760dd0c9b4f5fbb5b6d169df31a33073%40%3Cdev.cassandra.apache.org%3E

[8] 
https://lists.apache.org/thread.html/r5c0be74659f3696f310e3921cbbf7cecaf2ade0218397920dcfe3a4d%40%3Cdev.cassandra.apache.org%3E

[9] 
https://lists.apache.org/thread.html/reb0addf14d7d2307c8d2ca7422489484940cdf40a288d5625dabf265%40%3Cdev.cassandra.apache.org%3E

[10] 
https://lists.apache.org/thread.html/red7edd4f8be310a0d725ea0872d645dfceb43f7c3a6885db1ee3a244%40%3Cdev.cassandra.apache.org%3E

[11] 
https://lists.apache.org/thread.html/rd2c3b6a40ffa2530fb7898e3045efbd999f5e8f1619a56589bf29b8b%40%3Cdev.cassandra.apache.org%3E

[12] 
https://lists.apache.org/thread.html/r21f8f532986b2ae6bf80f31a162ce7652ef2fa93af8d6abbe259e21f%40%3Cdev.cassandra.apache.org%3E
[13] 
https://lists.apache.org/thread.html/re6734d8aadcc17f6f14e1e07b9d3483a3e7628b70d094980e3056c3b%40%3Cdev.cassandra.apache.org%3E






From: Mick Semb Wever 
Date: Thursday, 14 October 2021 at 22:08
To: dev@cassandra.apache.org 
Subject: 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 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 week, or two, before another vote risks the inclusion of
this CEP in this release cycle. I've

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

[Eric Evans]

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 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
2. +1
3. +1


>
> The first vote is a consensus vote of all committers, the second and third
> however are about project direction and therefore are simple majority votes
> of the PMC.
>
> Recall that all -1 votes must be accompanied by an explanation. If you
> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
> If a majority reject grounds (2) or (3) then transaction developments will
> halt for the time being.
>
> This vote will be open for 72 hours.
>

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

[Sumanth Pasupuleti]

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 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 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 week, or two, before another vote risks the inclusion of
> this CEP in this release cycle. I've certainly appreciated reading through
> every question raised, and wouldn't object to the CEP page being updated to
> include even more (but this is not a blocker for me).
>

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

[Mick Semb Wever]

>
> 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 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 week, or two, before another vote risks the inclusion of
this CEP in this release cycle. I've certainly appreciated reading through
every question raised, and wouldn't object to the CEP page being updated to
include even more (but this is not a blocker for me).

Re: Tradeoffs for Cassandra transaction management

[Jonathan Ellis]

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 what the Calvin team did to benchmark it.

-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: Tradeoffs for Cassandra transaction management

[bened...@apache.org]

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 must insist you specify your goal criteria, that I have requested 
six times already.

Please then specify a Calvin-compatible transaction and an explanation of why 
you believe Accord does not support it. To continue this discussion I must 
insist on concrete problems that you have invested the time to state clearly, 
with reasoned explanations using your present understanding of Accord to 
explain why you believe it does not work. This should ideally reference the 
actual protocol specified in the whitepaper. You should be able to demonstrate 
that you have invested the time to understand the proposal, and the problem 
case you perceive, in some reasonable level of detail.

Since you have asked no clarifying questions about the whitepaper in the past 
six weeks, I can only assume you believe yourself to understand it already, but 
in case any confusion has arisen your detailed explanation of the problem case 
will help me better understand what needs to be stated in response to your 
query.



From: Jonathan Ellis 
Date: Thursday, 14 October 2021 at 21:47
To: dev 
Subject: 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 discussion to Accord as it is today instead of engaging in
hypotheticals around how "we could enhance Accord with X."

On Thu, Oct 14, 2021 at 12:46 PM bened...@apache.org 
wrote:

> > 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 equivalent to Calvin. The locks for execution are
> isomorphic with any multi-shard distributed consensus protocol that applies
> its operations in the agreed partial order on each replica. If you want to
> continue this thread of discussion, please provide a counter example you
> believe disproves this statement.
>
>
> From: Jonathan Ellis 
> Date: Thursday, 14 October 2021 at 14:55
> To: dev 
> Subject: 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 the consensus and
> the execution algorithms, but if we can't use the former to create
> execution timestamps for a different transaction manager then it doesn't
> sound as flexible as you're claiming.
>
> To your other points, it looks like the core problem is that you believe
> that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
> not the case.  Calvin supports arbitrarily complex transactions (included
> dependent statements and indexed reads and writes), executed in parallel,
> with locking as necessary to enable that parallelism.
>
> 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.
>
> I'd prefer to keep the discussion on the mailing list, thanks.
>
>
> On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
> wrote:
>
> > Jonathan,
> >
> > Your request to separate consensus from execution is about as sensical as
> > asking for this separation in Paxos, or any other distributed consensus
> > protocol. I have made these statements repeatedly, so let me break it
> down
> > step by step.
> >
> > 1. Accord is an optimal leaderless distributed consensus protocol,
> > offering multi-shard CAS semantics in one round-trip (or two under
> > contention and clock skew).
> > 2. By simple virtue of this property, it already achieves Calvin
> semantics
> > with no other work. It remains a distributed consensus protocol, and the
> > whitepaper compares to these as peers.
> > 3. To build distributed transactions with more complex semantics, the
> > remaining candidates are the CockroachDB or YugaByte approach. These must
> > utilise a distributed consensus protocol. They do so using Raft today.
> > Accord is as optimal as Raft, therefore, Accord may be used to implement
> > this technique *without penalty*. Through its multi-shard consensus it
> has
> > the added advantage of

Re: Tradeoffs for Cassandra transaction management

[Jonathan Ellis]

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 discussion to Accord as it is today instead of engaging in
hypotheticals around how "we could enhance Accord with X."

On Thu, Oct 14, 2021 at 12:46 PM bened...@apache.org 
wrote:

> > 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 equivalent to Calvin. The locks for execution are
> isomorphic with any multi-shard distributed consensus protocol that applies
> its operations in the agreed partial order on each replica. If you want to
> continue this thread of discussion, please provide a counter example you
> believe disproves this statement.
>
>
> From: Jonathan Ellis 
> Date: Thursday, 14 October 2021 at 14:55
> To: dev 
> Subject: 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 the consensus and
> the execution algorithms, but if we can't use the former to create
> execution timestamps for a different transaction manager then it doesn't
> sound as flexible as you're claiming.
>
> To your other points, it looks like the core problem is that you believe
> that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
> not the case.  Calvin supports arbitrarily complex transactions (included
> dependent statements and indexed reads and writes), executed in parallel,
> with locking as necessary to enable that parallelism.
>
> 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.
>
> I'd prefer to keep the discussion on the mailing list, thanks.
>
>
> On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
> wrote:
>
> > Jonathan,
> >
> > Your request to separate consensus from execution is about as sensical as
> > asking for this separation in Paxos, or any other distributed consensus
> > protocol. I have made these statements repeatedly, so let me break it
> down
> > step by step.
> >
> > 1. Accord is an optimal leaderless distributed consensus protocol,
> > offering multi-shard CAS semantics in one round-trip (or two under
> > contention and clock skew).
> > 2. By simple virtue of this property, it already achieves Calvin
> semantics
> > with no other work. It remains a distributed consensus protocol, and the
> > whitepaper compares to these as peers.
> > 3. To build distributed transactions with more complex semantics, the
> > remaining candidates are the CockroachDB or YugaByte approach. These must
> > utilise a distributed consensus protocol. They do so using Raft today.
> > Accord is as optimal as Raft, therefore, Accord may be used to implement
> > this technique *without penalty*. Through its multi-shard consensus it
> has
> > the added advantage of supporting stronger isolation (but not requiring
> it
> > – a read/write intent design may choose weaker isolation).
> >
> > You continue to refuse to engage with these and other points. Please
> > respond directly to ALL of the below, that I have been asking you to
> answer
> > now for several weeks.
> >
> > 1. Since Accord supports all of your mooted transaction systems without
> > penalty the conversation about which semantics to pursue may be conducted
> > in parallel with its development. What about this claim do you not yet
> > understand? If you understand, why should a vote on CEP-15 be delayed?
> > 2. Which SPECIFIC transaction semantics do you want to achieve? You are
> > all over the shop today, demanding Cockroach/YugaByte interactive
> > semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are
> > conflicting demands.
> > 3. Why do you think Accord cannot support your preferred semantics?
> > 4. Will you accept a video call so we may discuss this with you in
> detail,
> > so we may understand your difficulty understanding these points I keep
> > repeating?
> >
> > After several weeks of back and forth you should already be able to
> answer
> > these questions. If you cannot invest the time to answer them now, I
> > perceive this as obstructive and I will escalate this to a PMC vote to
> > break the deadlock.
> >
> >
> >
> > From: Jonathan Ellis 
> > Date: Wednesday, 13 October 2021 at 0

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

[Dinesh Joshi]

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 on all points.

Benedict, thanks for putting together this CEP. I would love to see more
CEPs that use incremental approaches to improve features in Cassandra.

Dinesh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

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

[Jordan West]

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 direction. It also
seems to have been developed with high standards when it comes to quality
and testing which I applaud.

Jordan

On Thu, Oct 14, 2021 at 12:11 PM sankalp kohli 
wrote:

> +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
> > Cassandra user community to veto significant progress in this area on
> > grounds that the CEP does not contain a design for a feature that is a
> > non-goal of the initial scope proposed by the CEP, and which is also not
> > precluded by the CEP.
> >
> > - Scott
> >
> > > On Oct 14, 2021, at 11:27 AM, Aleksey Yeschenko 
> > wrote:
> > >
> > > +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 semantics proposed by the CEP for
> > Cassandra?
> > >> 3. Do you support an incremental approach to developing transactions
> in
> > Cassandra, leaving scope for future development?
> > >> The first vote is a consensus vote of all committers, the second and
> > third however are about project direction and therefore are simple
> majority
> > votes of the PMC.
> > >> Recall that all -1 votes must be accompanied by an explanation. If you
> > reject the CEP only on grounds (2) or (3) you should not veto the
> proposal.
> > If a majority reject grounds (2) or (3) then transaction developments
> will
> > halt for the time being.
> > >> This vote will be open for 72 hours.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

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

[sankalp kohli]

+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
> Cassandra user community to veto significant progress in this area on
> grounds that the CEP does not contain a design for a feature that is a
> non-goal of the initial scope proposed by the CEP, and which is also not
> precluded by the CEP.
>
> - Scott
>
> > On Oct 14, 2021, at 11:27 AM, Aleksey Yeschenko 
> wrote:
> >
> > +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 semantics proposed by the CEP for
> Cassandra?
> >> 3. Do you support an incremental approach to developing transactions in
> Cassandra, leaving scope for future development?
> >> The first vote is a consensus vote of all committers, the second and
> third however are about project direction and therefore are simple majority
> votes of the PMC.
> >> Recall that all -1 votes must be accompanied by an explanation. If you
> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
> If a majority reject grounds (2) or (3) then transaction developments will
> halt for the time being.
> >> This vote will be open for 72 hours.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [IDEA] Read committed transaction with Accord

[Henrik Ingo]

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 can't say I have any data or experience to say how important
it is to satisfy the use case you are outlining.

As a gut feeling, I believe the alternative proposal outlined by Alex and
Benedict would take such locks in the database nodes that you describe. But
again, we'll have to return to this another day as my today is almost over.

henrik

On Thu, Oct 14, 2021 at 7:39 PM Jonathan Ellis  wrote:

> ... 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 Jonathan Ellis  wrote:
>
> > [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 order ids
> > (increment district client = IDC).
> >
> > If we run these two workloads in postgresql under READ COMMITTED, both
> > clients will proceed happily (although we will get serialization
> anomalies).
> >
> > If we run them in pg under SERIALIZABLE, then the NOC client will get the
> > "could not serialize access" error whenever the IDC client updates the
> > district concurrently, which will be effectively every time since the IDC
> > transaction is much simpler.  But, SQL gives you a tool to allow NOC to
> > make progress, which is SELECT FOR UPDATE.  If the NOC performs its first
> > read with FOR UPDATE then it will (1) block until the current IDC
> > transaction completes and then (2) grab a lock that prevents further
> > updates from happening concurrently, allowing NOC to make progress.
> > Neither NOC nor IDC will ever get a "could not serialize access" error.
> >
> > It looks to me like the proposed design here would (1) not allow NOC to
> > make progress at READ COMMITTED, but also (2) does not provide the tools
> to
> > achieve progress with SERIALIZABLE either since locking outside of the
> > global consensus does not make sense.
> >
> > On Wed, Oct 13, 2021 at 1:59 PM Henrik Ingo 
> > wrote:
> >
> >> Sorry Jonathan, didn't see this reply earlier today.
> >>
> >> That would be common behaviour for many MVCC databases, including
> MongoDB,
> >> MySQL Galera Cluster, PostgreSQL...
> >>
> >>
> https://urldefense.com/v3/__https://www.postgresql.org/docs/9.5/transaction-iso.html__;!!PbtH5S7Ebw!KP0b2eRHpf-D6w1012nea4UbnsxtFn-zUEBrAZ7ghBFDr_QQyTT6qHzgZ0KKUKxt_64$
> >>
> >> *"Applications using this level must be prepared to retry transactions
> due
> >> to serialization failures."*
> >>
> >> On Wed, Oct 13, 2021 at 3:19 AM Jonathan Ellis 
> wrote:
> >>
> >> > Hi Henrik,
> >> >
> >> > I don't see how this resolves the fundamental problem that I outlined
> to
> >> > start with, namely, that without having the entire logic of the
> >> transaction
> >> > available to it, the server cannot retry the transaction when
> concurrent
> >> > changes are found to have been applied after the reconnaissance reads
> >> (what
> >> > you call the conversational phase).
> >
> >
> > On Wed, Oct 13, 2021 at 5:00 AM Henrik Ingo 
> > wrote:
> >
> >> On Wed, Oct 13, 2021 at 1:26 AM Blake Eggleston
> >>  wrote:
> >>
> >> > Hi Henrik,
> >> >
> >> > I would agree that the local serial experience for valid use cases
> >> should
> >> > be supported in some form before legacy LWT is replaced by Accord.
> >> >
> >> >
> >> Great! It seems there's a seed of consensus on this point.
> >>
> >>
> >> > Regarding your read committed proposal, I think this CEP discussion
> has
> >> > already spent too much time talking about hypothetical SQL
> >> implementations,
> >> > and I’d like to avoid veering off course again. However, since you’ve
> >> asked
> >> > a well thought out question with concrete goals and implementation
> >> ideas,
> >> > I’m happy to answer it. I just ask that if you want to discuss it
> >> beyond my
> >> > reply, you start a separate ‘[IDEA] Read committed transaction with
> >> Accord’
> >> > thread where we could talk about it a bit more without it feeling like
> >> we
> >> > need to delay a vote.
> >> >
> >> >
> >> This is a reasonable request. We were already in a side thread I guess,
> >> but
> >> I like organizing discussions into separate threads...
> >>
> >> Let's see if I manage to break the thread correctly simply by editing
> the
> >> subject...
> >>
> >> FWIW, my hope for this discussion was that by providing a simple yet
> >> concrete example, it would facilitate the

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

[C. Scott Andreas]

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 
CEP does not contain a design for a feature that is a non-goal of the initial 
scope proposed by the CEP, and which is also not precluded by the CEP.

- Scott

> On Oct 14, 2021, at 11:27 AM, Aleksey Yeschenko  wrote:
> 
> +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 semantics proposed by the CEP for 
>> Cassandra?
>> 3. Do you support an incremental approach to developing transactions in 
>> Cassandra, leaving scope for future development?
>> The first vote is a consensus vote of all committers, the second and third 
>> however are about project direction and therefore are simple majority votes 
>> of the PMC.
>> Recall that all -1 votes must be accompanied by an explanation. If you 
>> reject the CEP only on grounds (2) or (3) you should not veto the proposal. 
>> If a majority reject grounds (2) or (3) then transaction developments will 
>> halt for the time being.
>> This vote will be open for 72 hours.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

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

[Aleksey Yeschenko]

+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 semantics proposed by the CEP for Cassandra?
> 3. Do you support an incremental approach to developing transactions in 
> Cassandra, leaving scope for future development?
> 
> The first vote is a consensus vote of all committers, the second and third 
> however are about project direction and therefore are simple majority votes 
> of the PMC.
> 
> Recall that all -1 votes must be accompanied by an explanation. If you reject 
> the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
> majority reject grounds (2) or (3) then transaction developments will halt 
> for the time being.
> 
> This vote will be open for 72 hours.


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Tradeoffs for Cassandra transaction management

[bened...@apache.org]

> 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 equivalent to Calvin. The locks for execution are isomorphic with 
any multi-shard distributed consensus protocol that applies its operations in 
the agreed partial order on each replica. If you want to continue this thread 
of discussion, please provide a counter example you believe disproves this 
statement.


From: Jonathan Ellis 
Date: Thursday, 14 October 2021 at 14:55
To: dev 
Subject: 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 the consensus and
the execution algorithms, but if we can't use the former to create
execution timestamps for a different transaction manager then it doesn't
sound as flexible as you're claiming.

To your other points, it looks like the core problem is that you believe
that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
not the case.  Calvin supports arbitrarily complex transactions (included
dependent statements and indexed reads and writes), executed in parallel,
with locking as necessary to enable that parallelism.

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.

I'd prefer to keep the discussion on the mailing list, thanks.


On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
wrote:

> Jonathan,
>
> Your request to separate consensus from execution is about as sensical as
> asking for this separation in Paxos, or any other distributed consensus
> protocol. I have made these statements repeatedly, so let me break it down
> step by step.
>
> 1. Accord is an optimal leaderless distributed consensus protocol,
> offering multi-shard CAS semantics in one round-trip (or two under
> contention and clock skew).
> 2. By simple virtue of this property, it already achieves Calvin semantics
> with no other work. It remains a distributed consensus protocol, and the
> whitepaper compares to these as peers.
> 3. To build distributed transactions with more complex semantics, the
> remaining candidates are the CockroachDB or YugaByte approach. These must
> utilise a distributed consensus protocol. They do so using Raft today.
> Accord is as optimal as Raft, therefore, Accord may be used to implement
> this technique *without penalty*. Through its multi-shard consensus it has
> the added advantage of supporting stronger isolation (but not requiring it
> – a read/write intent design may choose weaker isolation).
>
> You continue to refuse to engage with these and other points. Please
> respond directly to ALL of the below, that I have been asking you to answer
> now for several weeks.
>
> 1. Since Accord supports all of your mooted transaction systems without
> penalty the conversation about which semantics to pursue may be conducted
> in parallel with its development. What about this claim do you not yet
> understand? If you understand, why should a vote on CEP-15 be delayed?
> 2. Which SPECIFIC transaction semantics do you want to achieve? You are
> all over the shop today, demanding Cockroach/YugaByte interactive
> semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are
> conflicting demands.
> 3. Why do you think Accord cannot support your preferred semantics?
> 4. Will you accept a video call so we may discuss this with you in detail,
> so we may understand your difficulty understanding these points I keep
> repeating?
>
> After several weeks of back and forth you should already be able to answer
> these questions. If you cannot invest the time to answer them now, I
> perceive this as obstructive and I will escalate this to a PMC vote to
> break the deadlock.
>
>
>
> From: Jonathan Ellis 
> Date: Wednesday, 13 October 2021 at 04:21
> To: dev 
> Subject: Re: Tradeoffs for Cassandra transaction management
> Blake (and Benedict), I’ll ask for your patience here.  We don’t have a
> precedent of pushing through major initiatives in this project in a matter
> of weeks.  We [members of the PMC that weren’t involved in creating Accord]
> need time to do thorough research and make sure both that we understand
> what is being proposed and that we have evaluated reasonable alternatives.
>
> One of the difficulties in evaluating Accord is that it combines a
> state-of-the-art consensus/ordering protocol with a fairly limited
> transaction manager.  So it may be useful to decoup

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

[bened...@apache.org]

> 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 interpret the outcome of 
this vote once it concludes and refine the community process to ensure this 
situation does not arise in future.

1. +1
2. +1
3. +1

From: Jonathan Ellis 
Date: Thursday, 14 October 2021 at 17:57
To: dev 
Subject: 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 from the
simple CAS operations supported by Accord to full SQL support with
interactive transactions, or even to Calvin-style deterministic
transactions with richer semantics.

2. -1, I'm not convinced that we want a one-size-fits-all approach and if
we do that Accord is the best one size.

3. +1, although obviously the devil is in the details.  I would support,
for instance, exposing any interfaces necessary in Cassandra to make it
feasible to maintain and use Accord as an out-of-tree plugin for the time
being. This lets work on Accord continue while not closing the door on
alternatives that make different tradeoffs.  I would also support, in that
world, CQL extensions that only work with Accord or other “next-gen”
transaction managers to start evolving our APIs past what LWT can handle.


On Thu, Oct 14, 2021 at 11:44 AM Jonathan Ellis  wrote:

> 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 consensus (3 binding +1 votes and no binding
> vetoes). The vote should remain open for 72 hours."
>
> No provision is made for declaring a CEP, or part of it, to be subject to
> a simple majority vote simply by claiming it's directional.
>
>
> 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 proposed by the CEP for
>> Cassandra?
>> 3. Do you support an incremental approach to developing transactions in
>> Cassandra, leaving scope for future development?
>>
>> The first vote is a consensus vote of all committers, the second and
>> third however are about project direction and therefore are simple majority
>> votes of the PMC.
>>
>> Recall that all -1 votes must be accompanied by an explanation. If you
>> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
>> If a majority reject grounds (2) or (3) then transaction developments will
>> halt for the time being.
>>
>> This vote will be open for 72 hours.
>>
>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>


--
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

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

[Jonathan Ellis]

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 from the
simple CAS operations supported by Accord to full SQL support with
interactive transactions, or even to Calvin-style deterministic
transactions with richer semantics.

2. -1, I'm not convinced that we want a one-size-fits-all approach and if
we do that Accord is the best one size.

3. +1, although obviously the devil is in the details.  I would support,
for instance, exposing any interfaces necessary in Cassandra to make it
feasible to maintain and use Accord as an out-of-tree plugin for the time
being. This lets work on Accord continue while not closing the door on
alternatives that make different tradeoffs.  I would also support, in that
world, CQL extensions that only work with Accord or other “next-gen”
transaction managers to start evolving our APIs past what LWT can handle.


On Thu, Oct 14, 2021 at 11:44 AM Jonathan Ellis  wrote:

> 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 consensus (3 binding +1 votes and no binding
> vetoes). The vote should remain open for 72 hours."
>
> No provision is made for declaring a CEP, or part of it, to be subject to
> a simple majority vote simply by claiming it's directional.
>
>
> 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 proposed by the CEP for
>> Cassandra?
>> 3. Do you support an incremental approach to developing transactions in
>> Cassandra, leaving scope for future development?
>>
>> The first vote is a consensus vote of all committers, the second and
>> third however are about project direction and therefore are simple majority
>> votes of the PMC.
>>
>> Recall that all -1 votes must be accompanied by an explanation. If you
>> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
>> If a majority reject grounds (2) or (3) then transaction developments will
>> halt for the time being.
>>
>> This vote will be open for 72 hours.
>>
>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

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

[Oleksandr Petrov]

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 semantics proposed by the CEP for
> Cassandra?
> 3. Do you support an incremental approach to developing transactions in
> Cassandra, leaving scope for future development?
>
> The first vote is a consensus vote of all committers, the second and third
> however are about project direction and therefore are simple majority votes
> of the PMC.
>
> Recall that all -1 votes must be accompanied by an explanation. If you
> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
> If a majority reject grounds (2) or (3) then transaction developments will
> halt for the time being.
>
> This vote will be open for 72 hours.
>


-- 
alex p

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

[Jonathan Ellis]

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 consensus (3 binding +1 votes and no binding vetoes). The
vote should remain open for 72 hours."

No provision is made for declaring a CEP, or part of it, to be subject to a
simple majority vote simply by claiming it's directional.


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 proposed by the CEP for
> Cassandra?
> 3. Do you support an incremental approach to developing transactions in
> Cassandra, leaving scope for future development?
>
> The first vote is a consensus vote of all committers, the second and third
> however are about project direction and therefore are simple majority votes
> of the PMC.
>
> Recall that all -1 votes must be accompanied by an explanation. If you
> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
> If a majority reject grounds (2) or (3) then transaction developments will
> halt for the time being.
>
> This vote will be open for 72 hours.
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

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

[Stefan Miklosovic]

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 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 developing transactions in 
> > Cassandra, leaving scope for future development?
> >
> > The first vote is a consensus vote of all committers, the second and third 
> > however are about project direction and therefore are simple majority votes 
> > of the PMC.
> >
> > Recall that all -1 votes must be accompanied by an explanation. If you 
> > reject the CEP only on grounds (2) or (3) you should not veto the proposal. 
> > If a majority reject grounds (2) or (3) then transaction developments will 
> > halt for the time being.
> >
> > This vote will be open for 72 hours.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [IDEA] Read committed transaction with Accord

[Jonathan Ellis]

... 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 Jonathan Ellis  wrote:

> [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 order ids
> (increment district client = IDC).
>
> If we run these two workloads in postgresql under READ COMMITTED, both
> clients will proceed happily (although we will get serialization anomalies).
>
> If we run them in pg under SERIALIZABLE, then the NOC client will get the
> "could not serialize access" error whenever the IDC client updates the
> district concurrently, which will be effectively every time since the IDC
> transaction is much simpler.  But, SQL gives you a tool to allow NOC to
> make progress, which is SELECT FOR UPDATE.  If the NOC performs its first
> read with FOR UPDATE then it will (1) block until the current IDC
> transaction completes and then (2) grab a lock that prevents further
> updates from happening concurrently, allowing NOC to make progress.
> Neither NOC nor IDC will ever get a "could not serialize access" error.
>
> It looks to me like the proposed design here would (1) not allow NOC to
> make progress at READ COMMITTED, but also (2) does not provide the tools to
> achieve progress with SERIALIZABLE either since locking outside of the
> global consensus does not make sense.
>
> On Wed, Oct 13, 2021 at 1:59 PM Henrik Ingo 
> wrote:
>
>> Sorry Jonathan, didn't see this reply earlier today.
>>
>> That would be common behaviour for many MVCC databases, including MongoDB,
>> MySQL Galera Cluster, PostgreSQL...
>>
>> https://www.postgresql.org/docs/9.5/transaction-iso.html
>>
>> *"Applications using this level must be prepared to retry transactions due
>> to serialization failures."*
>>
>> On Wed, Oct 13, 2021 at 3:19 AM Jonathan Ellis  wrote:
>>
>> > Hi Henrik,
>> >
>> > I don't see how this resolves the fundamental problem that I outlined to
>> > start with, namely, that without having the entire logic of the
>> transaction
>> > available to it, the server cannot retry the transaction when concurrent
>> > changes are found to have been applied after the reconnaissance reads
>> (what
>> > you call the conversational phase).
>
>
> On Wed, Oct 13, 2021 at 5:00 AM Henrik Ingo 
> wrote:
>
>> On Wed, Oct 13, 2021 at 1:26 AM Blake Eggleston
>>  wrote:
>>
>> > Hi Henrik,
>> >
>> > I would agree that the local serial experience for valid use cases
>> should
>> > be supported in some form before legacy LWT is replaced by Accord.
>> >
>> >
>> Great! It seems there's a seed of consensus on this point.
>>
>>
>> > Regarding your read committed proposal, I think this CEP discussion has
>> > already spent too much time talking about hypothetical SQL
>> implementations,
>> > and I’d like to avoid veering off course again. However, since you’ve
>> asked
>> > a well thought out question with concrete goals and implementation
>> ideas,
>> > I’m happy to answer it. I just ask that if you want to discuss it
>> beyond my
>> > reply, you start a separate ‘[IDEA] Read committed transaction with
>> Accord’
>> > thread where we could talk about it a bit more without it feeling like
>> we
>> > need to delay a vote.
>> >
>> >
>> This is a reasonable request. We were already in a side thread I guess,
>> but
>> I like organizing discussions into separate threads...
>>
>> Let's see if I manage to break the thread correctly simply by editing the
>> subject...
>>
>> FWIW, my hope for this discussion was that by providing a simple yet
>> concrete example, it would facilitate the discussion toward a CEP-15 vote,
>> not distract from it. As it happened, Alex Miller was writing a hugely
>> helpful email concurrently with mine, which improves details in CEP-15, so
>> I don't know if expecting the discussion to die out just yet is ignoring
>> people who maybe working off list to still understand this rather advanced
>> reading material.
>>
>>
>>
>> > So I think it could work with some modifications.
>> >
>> > First you’d need to perform your select statements as accord reads, not
>> > quorum reads. Otherwise you may not see writes that have been (or could
>> > have been) committed. A multi-partition write could also appear to
>> become
>> > undone, if a write commit has not reached one of the keys or needs to be
>> > recovered.
>> >
>>
>> Ah right. I think we established early on that tables should be either
>> Accord-only, or legacy C* only. I was too fixated on the "no other
>> changes"
>> and forgot this.
>>
>> This is then a very interesting detail you point out! It seems like
>> potentiall

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

[Blake Eggleston]

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 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?
> 
> The first vote is a consensus vote of all committers, the second and third 
> however are about project direction and therefore are simple majority votes 
> of the PMC.
> 
> Recall that all -1 votes must be accompanied by an explanation. If you reject 
> the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
> majority reject grounds (2) or (3) then transaction developments will halt 
> for the time being.
> 
> This vote will be open for 72 hours.


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

[VOTE] CEP-15: General Purpose Transactions

[bened...@apache.org]

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 developing transactions in 
Cassandra, leaving scope for future development?

The first vote is a consensus vote of all committers, the second and third 
however are about project direction and therefore are simple majority votes of 
the PMC.

Recall that all -1 votes must be accompanied by an explanation. If you reject 
the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
majority reject grounds (2) or (3) then transaction developments will halt for 
the time being.

This vote will be open for 72 hours.

Re: Tradeoffs for Cassandra transaction management

[bened...@apache.org]

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: Thursday, 14 October 2021 at 14:55
To: dev 
Subject: 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 the consensus and
the execution algorithms, but if we can't use the former to create
execution timestamps for a different transaction manager then it doesn't
sound as flexible as you're claiming.

To your other points, it looks like the core problem is that you believe
that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
not the case.  Calvin supports arbitrarily complex transactions (included
dependent statements and indexed reads and writes), executed in parallel,
with locking as necessary to enable that parallelism.

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.

I'd prefer to keep the discussion on the mailing list, thanks.


On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
wrote:

> Jonathan,
>
> Your request to separate consensus from execution is about as sensical as
> asking for this separation in Paxos, or any other distributed consensus
> protocol. I have made these statements repeatedly, so let me break it down
> step by step.
>
> 1. Accord is an optimal leaderless distributed consensus protocol,
> offering multi-shard CAS semantics in one round-trip (or two under
> contention and clock skew).
> 2. By simple virtue of this property, it already achieves Calvin semantics
> with no other work. It remains a distributed consensus protocol, and the
> whitepaper compares to these as peers.
> 3. To build distributed transactions with more complex semantics, the
> remaining candidates are the CockroachDB or YugaByte approach. These must
> utilise a distributed consensus protocol. They do so using Raft today.
> Accord is as optimal as Raft, therefore, Accord may be used to implement
> this technique *without penalty*. Through its multi-shard consensus it has
> the added advantage of supporting stronger isolation (but not requiring it
> – a read/write intent design may choose weaker isolation).
>
> You continue to refuse to engage with these and other points. Please
> respond directly to ALL of the below, that I have been asking you to answer
> now for several weeks.
>
> 1. Since Accord supports all of your mooted transaction systems without
> penalty the conversation about which semantics to pursue may be conducted
> in parallel with its development. What about this claim do you not yet
> understand? If you understand, why should a vote on CEP-15 be delayed?
> 2. Which SPECIFIC transaction semantics do you want to achieve? You are
> all over the shop today, demanding Cockroach/YugaByte interactive
> semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are
> conflicting demands.
> 3. Why do you think Accord cannot support your preferred semantics?
> 4. Will you accept a video call so we may discuss this with you in detail,
> so we may understand your difficulty understanding these points I keep
> repeating?
>
> After several weeks of back and forth you should already be able to answer
> these questions. If you cannot invest the time to answer them now, I
> perceive this as obstructive and I will escalate this to a PMC vote to
> break the deadlock.
>
>
>
> From: Jonathan Ellis 
> Date: Wednesday, 13 October 2021 at 04:21
> To: dev 
> Subject: Re: Tradeoffs for Cassandra transaction management
> Blake (and Benedict), I’ll ask for your patience here.  We don’t have a
> precedent of pushing through major initiatives in this project in a matter
> of weeks.  We [members of the PMC that weren’t involved in creating Accord]
> need time to do thorough research and make sure both that we understand
> what is being proposed and that we have evaluated reasonable alternatives.
>
> One of the difficulties in evaluating Accord is that it combines a
> state-of-the-art consensus/ordering protocol with a fairly limited
> transaction manager.  So it may be useful to decouple the consensus and
> transaction processing components, which would both allow non-Cassandra
> usage of the consensus piece, and also make explicit the boundaries with
> transaction processing with the consequence of making it easier to evolve
> independently.
>
> In the meantime, it’s very important to me to understand on which
> dimen

Re: [IDEA] Read committed transaction with Accord

[Jonathan Ellis]

 [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 order ids
(increment district client = IDC).

If we run these two workloads in postgresql under READ COMMITTED, both
clients will proceed happily (although we will get serialization anomalies).

If we run them in pg under SERIALIZABLE, then the NOC client will get the
"could not serialize access" error whenever the IDC client updates the
district concurrently, which will be effectively every time since the IDC
transaction is much simpler.  But, SQL gives you a tool to allow NOC to
make progress, which is SELECT FOR UPDATE.  If the NOC performs its first
read with FOR UPDATE then it will (1) block until the current IDC
transaction completes and then (2) grab a lock that prevents further
updates from happening concurrently, allowing NOC to make progress.
Neither NOC nor IDC will ever get a "could not serialize access" error.

It looks to me like the proposed design here would (1) not allow NOC to
make progress at READ COMMITTED, but also (2) does not provide the tools to
achieve progress with SERIALIZABLE either since locking outside of the
global consensus does not make sense.

On Wed, Oct 13, 2021 at 1:59 PM Henrik Ingo 
wrote:

> Sorry Jonathan, didn't see this reply earlier today.
>
> That would be common behaviour for many MVCC databases, including MongoDB,
> MySQL Galera Cluster, PostgreSQL...
>
> https://www.postgresql.org/docs/9.5/transaction-iso.html
>
> *"Applications using this level must be prepared to retry transactions due
> to serialization failures."*
>
> On Wed, Oct 13, 2021 at 3:19 AM Jonathan Ellis  wrote:
>
> > Hi Henrik,
> >
> > I don't see how this resolves the fundamental problem that I outlined to
> > start with, namely, that without having the entire logic of the
> transaction
> > available to it, the server cannot retry the transaction when concurrent
> > changes are found to have been applied after the reconnaissance reads
> (what
> > you call the conversational phase).


On Wed, Oct 13, 2021 at 5:00 AM Henrik Ingo 
wrote:

> On Wed, Oct 13, 2021 at 1:26 AM Blake Eggleston
>  wrote:
>
> > Hi Henrik,
> >
> > I would agree that the local serial experience for valid use cases should
> > be supported in some form before legacy LWT is replaced by Accord.
> >
> >
> Great! It seems there's a seed of consensus on this point.
>
>
> > Regarding your read committed proposal, I think this CEP discussion has
> > already spent too much time talking about hypothetical SQL
> implementations,
> > and I’d like to avoid veering off course again. However, since you’ve
> asked
> > a well thought out question with concrete goals and implementation ideas,
> > I’m happy to answer it. I just ask that if you want to discuss it beyond
> my
> > reply, you start a separate ‘[IDEA] Read committed transaction with
> Accord’
> > thread where we could talk about it a bit more without it feeling like we
> > need to delay a vote.
> >
> >
> This is a reasonable request. We were already in a side thread I guess, but
> I like organizing discussions into separate threads...
>
> Let's see if I manage to break the thread correctly simply by editing the
> subject...
>
> FWIW, my hope for this discussion was that by providing a simple yet
> concrete example, it would facilitate the discussion toward a CEP-15 vote,
> not distract from it. As it happened, Alex Miller was writing a hugely
> helpful email concurrently with mine, which improves details in CEP-15, so
> I don't know if expecting the discussion to die out just yet is ignoring
> people who maybe working off list to still understand this rather advanced
> reading material.
>
>
>
> > So I think it could work with some modifications.
> >
> > First you’d need to perform your select statements as accord reads, not
> > quorum reads. Otherwise you may not see writes that have been (or could
> > have been) committed. A multi-partition write could also appear to become
> > undone, if a write commit has not reached one of the keys or needs to be
> > recovered.
> >
>
> Ah right. I think we established early on that tables should be either
> Accord-only, or legacy C* only. I was too fixated on the "no other changes"
> and forgot this.
>
> This is then a very interesting detail you point out! It seems like
> potentially every statement now needs to go through the Accord consensus
> protocol, and this could become expensive, where my goal was to design the
> simplest and most lightweight example thinkable. BUT for read-only Accord
> transactions, where I specifically also don't care about serializability,
> wouldn't this be precisely the case where I can simply pick my own
> timestamp and do a stale read from a  nearby replica?
>
>
> >
> > Second, when you talk about transforming mutation

Re: Tradeoffs for Cassandra transaction management

[Jeff Jirsa]

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  wrote:

> 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 the consensus and
> the execution algorithms, but if we can't use the former to create
> execution timestamps for a different transaction manager then it doesn't
> sound as flexible as you're claiming.
>
> To your other points, it looks like the core problem is that you believe
> that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
> not the case.  Calvin supports arbitrarily complex transactions (included
> dependent statements and indexed reads and writes), executed in parallel,
> with locking as necessary to enable that parallelism.
>
> 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.
>
> I'd prefer to keep the discussion on the mailing list, thanks.
>
>
> On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
> wrote:
>
> > Jonathan,
> >
> > Your request to separate consensus from execution is about as sensical as
> > asking for this separation in Paxos, or any other distributed consensus
> > protocol. I have made these statements repeatedly, so let me break it
> down
> > step by step.
> >
> > 1. Accord is an optimal leaderless distributed consensus protocol,
> > offering multi-shard CAS semantics in one round-trip (or two under
> > contention and clock skew).
> > 2. By simple virtue of this property, it already achieves Calvin
> semantics
> > with no other work. It remains a distributed consensus protocol, and the
> > whitepaper compares to these as peers.
> > 3. To build distributed transactions with more complex semantics, the
> > remaining candidates are the CockroachDB or YugaByte approach. These must
> > utilise a distributed consensus protocol. They do so using Raft today.
> > Accord is as optimal as Raft, therefore, Accord may be used to implement
> > this technique *without penalty*. Through its multi-shard consensus it
> has
> > the added advantage of supporting stronger isolation (but not requiring
> it
> > – a read/write intent design may choose weaker isolation).
> >
> > You continue to refuse to engage with these and other points. Please
> > respond directly to ALL of the below, that I have been asking you to
> answer
> > now for several weeks.
> >
> > 1. Since Accord supports all of your mooted transaction systems without
> > penalty the conversation about which semantics to pursue may be conducted
> > in parallel with its development. What about this claim do you not yet
> > understand? If you understand, why should a vote on CEP-15 be delayed?
> > 2. Which SPECIFIC transaction semantics do you want to achieve? You are
> > all over the shop today, demanding Cockroach/YugaByte interactive
> > semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are
> > conflicting demands.
> > 3. Why do you think Accord cannot support your preferred semantics?
> > 4. Will you accept a video call so we may discuss this with you in
> detail,
> > so we may understand your difficulty understanding these points I keep
> > repeating?
> >
> > After several weeks of back and forth you should already be able to
> answer
> > these questions. If you cannot invest the time to answer them now, I
> > perceive this as obstructive and I will escalate this to a PMC vote to
> > break the deadlock.
> >
> >
> >
> > From: Jonathan Ellis 
> > Date: Wednesday, 13 October 2021 at 04:21
> > To: dev 
> > Subject: Re: Tradeoffs for Cassandra transaction management
> > Blake (and Benedict), I’ll ask for your patience here.  We don’t have a
> > precedent of pushing through major initiatives in this project in a
> matter
> > of weeks.  We [members of the PMC that weren’t involved in creating
> Accord]
> > need time to do thorough research and make sure both that we understand
> > what is being proposed and that we have evaluated reasonable
> alternatives.
> >
> > One of the difficulties in evaluating Accord is that it combines a
> > state-of-the-art consensus/ordering protocol with a fairly limited
> > transaction manager.  So it may be useful to decouple the consensus and
> > transaction processing components, which would both allow non-Cassandra
> > usage of the consensus piece, and also make explicit the boundaries with
> > transaction processing with the consequence of making it easier to evolv

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

[Stefan Miklosovic]

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.
> >
> > It seems to me CEP-16 is so straightforward there is more or less
> > nothing to discuss in more depth as the feedback it gathered was
> > mostly formal and nobody has had any objections so far having the
> > discussion thread open for such a long time.
> >
> > The vote is open for 72 hours based on the guidelines, it needs at
> > least 3 binding +1's and no vetoes.
> >
> > I am +1 on this.
> >
> > Regards
> >
> > (1) 
> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-16%3A+Auth+Plugin+Support+for+CQLSH
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Tradeoffs for Cassandra transaction management

[Jonathan Ellis]

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 the consensus and
the execution algorithms, but if we can't use the former to create
execution timestamps for a different transaction manager then it doesn't
sound as flexible as you're claiming.

To your other points, it looks like the core problem is that you believe
that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
not the case.  Calvin supports arbitrarily complex transactions (included
dependent statements and indexed reads and writes), executed in parallel,
with locking as necessary to enable that parallelism.

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.

I'd prefer to keep the discussion on the mailing list, thanks.


On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
wrote:

> Jonathan,
>
> Your request to separate consensus from execution is about as sensical as
> asking for this separation in Paxos, or any other distributed consensus
> protocol. I have made these statements repeatedly, so let me break it down
> step by step.
>
> 1. Accord is an optimal leaderless distributed consensus protocol,
> offering multi-shard CAS semantics in one round-trip (or two under
> contention and clock skew).
> 2. By simple virtue of this property, it already achieves Calvin semantics
> with no other work. It remains a distributed consensus protocol, and the
> whitepaper compares to these as peers.
> 3. To build distributed transactions with more complex semantics, the
> remaining candidates are the CockroachDB or YugaByte approach. These must
> utilise a distributed consensus protocol. They do so using Raft today.
> Accord is as optimal as Raft, therefore, Accord may be used to implement
> this technique *without penalty*. Through its multi-shard consensus it has
> the added advantage of supporting stronger isolation (but not requiring it
> – a read/write intent design may choose weaker isolation).
>
> You continue to refuse to engage with these and other points. Please
> respond directly to ALL of the below, that I have been asking you to answer
> now for several weeks.
>
> 1. Since Accord supports all of your mooted transaction systems without
> penalty the conversation about which semantics to pursue may be conducted
> in parallel with its development. What about this claim do you not yet
> understand? If you understand, why should a vote on CEP-15 be delayed?
> 2. Which SPECIFIC transaction semantics do you want to achieve? You are
> all over the shop today, demanding Cockroach/YugaByte interactive
> semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are
> conflicting demands.
> 3. Why do you think Accord cannot support your preferred semantics?
> 4. Will you accept a video call so we may discuss this with you in detail,
> so we may understand your difficulty understanding these points I keep
> repeating?
>
> After several weeks of back and forth you should already be able to answer
> these questions. If you cannot invest the time to answer them now, I
> perceive this as obstructive and I will escalate this to a PMC vote to
> break the deadlock.
>
>
>
> From: Jonathan Ellis 
> Date: Wednesday, 13 October 2021 at 04:21
> To: dev 
> Subject: Re: Tradeoffs for Cassandra transaction management
> Blake (and Benedict), I’ll ask for your patience here.  We don’t have a
> precedent of pushing through major initiatives in this project in a matter
> of weeks.  We [members of the PMC that weren’t involved in creating Accord]
> need time to do thorough research and make sure both that we understand
> what is being proposed and that we have evaluated reasonable alternatives.
>
> One of the difficulties in evaluating Accord is that it combines a
> state-of-the-art consensus/ordering protocol with a fairly limited
> transaction manager.  So it may be useful to decouple the consensus and
> transaction processing components, which would both allow non-Cassandra
> usage of the consensus piece, and also make explicit the boundaries with
> transaction processing with the consequence of making it easier to evolve
> independently.
>
> In the meantime, it’s very important to me to understand on which
> dimensions the transaction manager can be improved easily, and which
> dimensions resist such improvement.  I get that Accord is your [plural]
> baby and it’s awkward for me to come along and start pointing at its
> limitations, but that’s part of creating a complete understanding of any
> system.
>
> If I keep coming back to the subject of SQL support and interactive
> transactions, that’s because