Got it. Thanks for the extra context.
No real opinion here. :) On Wed, Nov 11, 2020 at 11:29 AM Benedict Elliott Smith <bened...@apache.org> wrote: > It's been there since the beginning. > > If we were to consider the alternative proposal for 4.0, it would not have > to be blocking for release. I had planned to come forward after 4.0, > primarily because I did not want to create further political complexities > for the project at this time, but also because I do not presently have the > time to produce all of the documentation we might like for such a proposal. > However, the work is ready, has already been reviewed by multiple > committers, has had more extensive testing than any feature I'm aware of to > date, and could be made available for 4.0 in fairly short order. While the > work itself is non-trivial, the work to integrate it is not complex. It > would also be optional, and configurable at runtime. > > The only likely blocker would be the process of review, and any other due > diligence the project might want to undertake. Absolutely not something I > advocate for or against an accelerated timescale on. I have no personal > preference for the approach taken, just providing this for context. > > > On 11/11/2020, 16:18, "Joshua McKenzie" <jmcken...@apache.org> wrote: > > How old is the C-12126 surfaced defect? i.e. is this a thing we've had > since initial introduction of paxos or is it a regression we introduced > somewhere along the way? > > On Wed, Nov 11, 2020 at 11:03 AM Benjamin Lerer < > benjamin.le...@datastax.com> > wrote: > > > CASSANDRA-12126 addresses one correctness issue of Light Weight > > Transactions. Unfortunately, the current patch developed by Sylvain > and > > Benedict requires an extra round trip between the coordinator and the > > replicas for SERIAL and LOCAL_SERIAL reads. > > After some experimentations, Benedict discovered that this extra > round trip > > could lead to a significant increase in timeouts for read-heavy > workloads. > > > > Users for which this behavior is a problem will be able to switch > back to > > the old behavior using a system property, therefore choosing > performance > > versus correctness. > > > > On the side, Benedict has worked on another approach that does not > suffer > > from that performance problem and also addresses some LWT correctness > > issues that can happen when adding or removing nodes. He initially > intended > > to deliver that improvement in 4.X but can try to incorporate it > into 4.0. > > > > Regarding CASSANDRA-12126 and 4.0 we are facing several options and > > Benedict, Sylvain and I wanted to get the community feedback on them. > > > > We can: > > > > 1. Try to use Benedict proposal for 4.0 if the community has the > > appetite for it. The main issue there is some potential extra > delay for > > 4.0 > > 2. Do nothing for 4.0. Meaning do not commit the current patch. > We have > > lived a long time with that issue and we can probably wait a bit > more > > for a > > proper solution. > > 3. Commit the patch as such, fixing the correctness but > introducing > > potentially some performance issue until we release a better > solution. > > 4. Changing the patch to default to the current behavior but > allowing > > people to enable the new one if the correctness is a problem for > them. > > > > Thanks in advance for your feedback. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
