[
https://issues.apache.org/jira/browse/CASSANDRA-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038008#comment-14038008
]
sankalp kohli commented on CASSANDRA-7344:
------------------------------------------
"Besides, the last accepted commit will generally not be empty unless no update
have ever been committed on the partition, so in practice we'd always have to
do the prepare and thus have 2 round-trips in general instead of one."
I was not clear before. What I am proposing is that we gather last accepted
ballot from all eligible replicas based on CL and if there is anything pending,
then do a full prepare propose or call the beginAndRepairPaxos method.
// If we have an in-progress ballot greater than the MRC we know, then it's an
in-progress round that
// needs to be completed, so do it.
if (!inProgress.update.isEmpty() && inProgress.isAfter(mostRecent))
Here in the code, we do a prepare phase to find out about any pending operation
and try to finish it.
"So we'd need one round-trip to get the last accepted commit, which is not
better that doing the prepare. "
It is better since there won't be any contention if more than one read is
issued for the same row. Here is an example
Say for a row A, all previous CAS operations have finished. There is nothing
pending.
Now 2 reads come for the same row at SERIAL, they can potentially contend with
each other in the prepare phase.
This contention can be avoided by asking eligible replicas for unfinished
operation for the given row and not doing a prepare.
> Read at SERIAL can lead to unnecessary contention
> --------------------------------------------------
>
> Key: CASSANDRA-7344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7344
> Project: Cassandra
> Issue Type: Improvement
> Reporter: sankalp kohli
> Assignee: sankalp kohli
> Priority: Minor
>
> If two clients are doing a read at serial on the same row, it does a full
> prepare step to figure out whether there is any updates or cas in flight or
> uncompleted.
> This can cause contention between then leading to waste of time in retrying.
> One of the request will not get a promise and will need to sleep.
> Instead they can check whether there is anything to finish and if not
> continue.
> If there is something to be done, then they can do the full prepare.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
