Re: [IDEA] Read committed transaction with Accord

2021-10-14 Thread Henrik Ingo
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

Re: [IDEA] Read committed transaction with Accord

2021-10-14 Thread Jonathan Ellis
> > >> 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, >> >

Re: [IDEA] Read committed transaction with Accord

2021-10-14 Thread Jonathan Ellis
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 > Acc

Re: [IDEA] Read committed transaction with Accord

2021-10-13 Thread Henrik Ingo
On Wed, Oct 13, 2021 at 3:38 PM bened...@apache.org wrote: > It may have been lost in the back and forth (there’s been a lot of > emails), but I outlined an approach for READ COMMITTED (and SERIALIZABLE) > read isolation that does not require a WAN trip. Yes, thank you. I knew I had read it but

Re: [IDEA] Read committed transaction with Accord

2021-10-13 Thread bened...@apache.org
> 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 s

[IDEA] Read committed transaction with Accord

2021-10-13 Thread Henrik Ingo
als 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. > &g