Ariel Weisberg commented on CASSANDRA-14448:

How does asynchronous commit make any case worse? Sure it can't make contention 
better. It can't make values become visible to readers faster. But it does mean 
that you get a faster response for updates and then your program can move on to 
the next thing. If your DCs are 70 milliseconds apart this is kind of a big 
deal. Applications do have upper bounds on response time where this is the 
difference between LWT being viable or not.

Many applications don't need to read again immediately because they just wrote 
the value so they already know the current state.

Regarding combining the read with the prepare. I think optimizing for the 
contended case in a system which has mostly punted on handling contention 
doesn't make much sense. This is something that we can make an option if it's 
shown that combining the read and the prepare negatively impacts the contended 
case. It might actually make it better by shrinking the window where LWTs can 
conflict since they get done faster. 

> Improve the performance of CAS
> ------------------------------
>                 Key: CASSANDRA-14448
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14448
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Dikang Gu
>            Assignee: Dikang Gu
>            Priority: Major
> I'm working on some performance improvements of the lightweight transitions 
> (compare and set).
> As you know, current CAS requires 4 round trips to finish, which is not 
> efficient, especially in cross DC case.
> 1) Prepare
> 2) Quorum read current value
> 3) Propose new value
> 4) Commit
> I'm proposing the following improvements to reduce it to 2 round trips, which 
> is:
> 1) Combine prepare and quorum read together, use only one round trip to 
> decide the ballot and also piggyback the current value in response.
> 2) Propose new value, and then send out the commit request asynchronously, so 
> client will not wait for the ack of the commit. In case of commit failures, 
> we should still have chance to retry/repair it through hints or following 
> read/cas events.
> After the improvement, we should be able to finish the CAS operation using 2 
> rounds trips. There can be following improvements as well, and this can be a 
> start point.

This message was sent by Atlassian JIRA

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

Reply via email to