Hi Jonathan, You are missing the woods for the trees here. You outlined several transaction systems, and I have demonstrated that Accord brings them *all* closer.
The immediate context of this discussion is that you are unhappy with CEP-15 due to its impact on a future transaction system. Given the above, it remains unclear why this is still an issue. I’m happy to continue a long-term roadmap discussion, but without specific further criticisms of CEP-15 we are long overdue a vote. From: Jonathan Ellis <jbel...@gmail.com> Date: Tuesday, 12 October 2021 at 02:35 To: dev <dev@cassandra.apache.org> Subject: Re: Tradeoffs for Cassandra transaction management On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org <bened...@apache.org> wrote: > If we want to fully unpack this particular point, as far as I can tell > claiming ANSI SQL would indeed require interactive transactions in which > arbitrary conditional work may be performed by a client within a > transaction in response to other actions within that transaction. > > However: > > 1. The ANSI SQL standard permits these transactions to fail and > rollback (e.g. in the event that your optimistic transaction fails). So if > you want to be pedantic, you may modify my statement to “SQL does not > necessitate support for abort-free interactive transactions” and we can > leave it there. > > 2. I would personally consider “SQL support” to include the capability > of defining arbitrary SQL stored procedures that may be executed by clients > in an interactive session I note your personal preference and I further note that this is not the common understanding of "SQL support" in the industry. If you tell 100 developers that your database supports SQL, then at least 99 of them are going to assume that you can work with APIs like JDBC that expose interactive transactions as a central feature, and hence that you will be reasonably compatible with the vast array of SQL-based applications out there. Historical side note: VoltDB tried to convince people that stored procedures were good enough. It didn't work, and VoltDB had to add interactive transactions as fast as they could. 3. Most importantly, as I pointed out in the previous email, Accord is > compatible with a YugaByte/Cockroach-like approach, and indeed makes this > approach both easier to accomplish and enables stronger isolation than the > equivalent Raft-based approach. These approaches are able to reduce the > number of conflicts, at a cost of significantly higher transaction > management burden. > If you're saying that you could use Accord instead of Raft or Paxos, and layer 2PC on top of that as in Spanner, then I agree, but I don't think that is a very good design, as you would no longer get any of the benefits of the deterministic approach you started with. If you mean something else, then perhaps an example would help clarify. -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
