Given the extensiveness and complexity of the proposal I'd suggest leaving
it a little longer (perhaps 4 weeks from the publish date?) for people to
get a bit more familiarized and have the chance to comment before casting a
vote. I glanced through the proposal - and it looks outstanding, very
promising work guys! - but would like a bit more time to take a deeper look
and digest it before potentially commenting on it.

Em ter., 14 de set. de 2021 às 17:30, bened...@apache.org <
bened...@apache.org> escreveu:

> Has anyone had a chance to read the drafts, and has any feedback or
> questions? Does anybody still anticipate doing so in the near future? Or
> shall we move to a vote?
>
> From: bened...@apache.org <bened...@apache.org>
> Date: Tuesday, 7 September 2021 at 21:27
> To: dev@cassandra.apache.org <dev@cassandra.apache.org>
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
> Hi Jake,
>
> > What structural changes are planned to support an external dependency
> project like this
>
> To add to Blake’s answer, in case there’s some confusion over this, the
> proposal is to include this library within the Apache Cassandra project. So
> I wouldn’t think of it as an external dependency. This PMC and community
> will still have the usual oversight over direction and development, and
> APIs will be developed solely with the intention of their integration with
> Cassandra.
>
> > Will this effort eventually replace consistency levels in C*?
>
> I hope we’ll have some very related discussions around consistency levels
> in the coming months more generally, but I don’t think that is tightly
> coupled to this work. I agree with you both that we won’t want to
> perpetuate the problems you’ve highlighted though.
>
> Henrik:
> > I was referring to the property that Calvin transactions also need to be
> sent to the cluster in a single shot
>
> Ah, yes. In that case I agree, and I tried to point to this direction in
> an earlier email, where I discussed the use of scripting languages (i.e.
> transactionally modifying the database with some subset of arbitrary
> computation). I think the JVM is particularly suited to offering quite
> powerful distributed transactions in this vein, and it will be interesting
> to see what we might develop in this direction in future.
>
>
> From: Jake Luciani <jak...@gmail.com>
> Date: Tuesday, 7 September 2021 at 19:27
> To: dev@cassandra.apache.org <dev@cassandra.apache.org>
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
> Great thanks for the information
>
> On Tue, Sep 7, 2021 at 12:44 PM Blake Eggleston
> <beggles...@apple.com.invalid> wrote:
>
> > Hi Jake,
> >
> > > 1.  Will this effort eventually replace consistency levels in C*?  I
> ask
> > > because one of the shortcomings of our paxos today is
> > > it can be easily mixed with non serialized consistencies and therefore
> > > users commonly break consistency by for example reading at CL.ONE while
> > > also
> > > using LWTs.
> >
> > This will likely require CLs to be specified at the schema level for
> > tables using multi partition transactions. I’d expect this to be
> available
> > for other tables, but not required.
> >
> > > 2. What structural changes are planned to support an external
> dependency
> > > project like this?  Are there some high level interfaces you expect the
> > > project to adhere to?
> >
> > There will be some interfaces that need to be implemented in C* to
> support
> > the library. You can find the current interfaces in the accord.api
> package,
> > but these were written to support some initial testing, and not intended
> > for integration into C* as is. Things are pretty fluid right now and will
> > be rewritten / refactored multiple times over the next few months.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > > On Sun, Sep 5, 2021 at 10:33 AM bened...@apache.org <
> bened...@apache.org
> > >
> > > wrote:
> > >
> > >> Wiki:
> > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions
> > >> Whitepaper:
> > >>
> >
> https://cwiki.apache.org/confluence/download/attachments/188744725/Accord.pdf
> > >> <
> > >>
> >
> https://cwiki.apache.org/confluence/download/attachments/188744725/Accord.pdf?version=1&modificationDate=1630847736966&api=v2
> > >>>
> > >> Prototype: https://github.com/belliottsmith/accord
> > >>
> > >> Hi everyone, I’d like to propose this CEP for adoption by the
> community.
> > >>
> > >> Cassandra has benefitted from LWTs for many years, but application
> > >> developers that want to ensure consistency for complex operations must
> > >> either accept the scalability bottleneck of serializing all related
> > state
> > >> through a single partition, or layer a complex state machine on top of
> > the
> > >> database. These are sophisticated and costly activities that our users
> > >> should not be expected to undertake. Since distributed databases are
> > >> beginning to offer distributed transactions with fewer caveats, it is
> > past
> > >> time for Cassandra to do so as well.
> > >>
> > >> This CEP proposes the use of several novel techniques that build upon
> > >> research (that followed EPaxos) to deliver (non-interactive) general
> > >> purpose distributed transactions. The approach is outlined in the
> > wikipage
> > >> and in more detail in the linked whitepaper. Importantly, by adopting
> > this
> > >> approach we will be the _only_ distributed database to offer global,
> > >> scalable, strict serializable transactions in one wide area
> round-trip.
> > >> This would represent a significant improvement in the state of the
> art,
> > >> both in the academic literature and in commercial or open source
> > offerings.
> > >>
> > >> This work has been partially realised in a prototype. This partial
> > >> prototype has been verified against Jepsen.io’s Maelstrom library and
> > >> dedicated in-tree strict serializability verification tools, but much
> > work
> > >> remains for the work to be production capable and integrated into
> > Cassandra.
> > >>
> > >> I propose including the prototype in the project as a new source
> > >> repository, to be developed as a standalone library for integration
> into
> > >> Cassandra. I hope the community sees the important value proposition
> of
> > >> this proposal, and will adopt the CEP after this discussion, so that
> the
> > >> library and its integration into Cassandra can be developed in
> parallel
> > and
> > >> with the involvement of the wider community.
> > >>
> > >
> > >
> > > --
> > > http://twitter.com/tjake
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake
>

Reply via email to