[
https://issues.apache.org/jira/browse/CASSANDRA-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479778#comment-16479778
]
Ariel Weisberg commented on CASSANDRA-14448:
--------------------------------------------
bq. The coordinator sends the new prepare command to quorum replicas, on each
replica, it loads it's paxos state, and then it can compare it's promised
ballot with the new ballot received from coordinator. If it's local promised
ballot is greater than the one received from coordinator, then it's going to
reject the ballot, and there is no need to execute the read command any more.
In this case, we can avoid one read on the replica.
Makes sense to me.
In the local DC case there is a possibility you are better off doing the ballot
check concurrent with the read so that the window for dueling proposers is
smaller. It depends on a bunch of unknown and possibly workload dependent
factors. Even if you measured it both ways it would be hard to be confident.
In the multi-DC case it doesn't really matter and you are going to be wildly
better off even if you do the read conditional on the ballot.
On an unrelated note it looks like {{beginAndRepairPaxos}} uses as
{{consistencyForCommit}} the value of the current operation rather than the
value of the operation that originally left an in progress operation. I wonder
if that could be a problem in practice.
> 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
