[
https://issues.apache.org/jira/browse/CASSANDRA-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479412#comment-16479412
]
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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
