[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627707#comment-13627707
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
bq. this sounds exactly like what we discussed to preserve correctness
Not exactly. What we need to preserve correctness is make sure we don't start a
new round (i.e. we don't propose our own value) until we can guarantee that a
quorum of replica have learned about the last MRC. And that is correctly done
by this patch, I'm not contesting that. However, the patch equates "not
starting a new round" with "throwing an UAE", which is what I have a problem
with.
Let me put it another way: the reason why I suggested storing the
mostRecentUpdate is so that if we get in a state where less than a quorum of
replica have learned the last commit due to some errors, then we can repair
them by sending them that mostRecentUpdate (after which we'd be able to make
progress again). But that's not what the current patch does. The only time the
current patch uses the mostRecentUpdate is when we have already validated that
we have a quorum of node on the MRC. In other words, it uses the
mostRecentUpdate only as a slight optimisation but not to avoid the algorithm
getting stuck, which should be the main goal (the only goal really imo).
Anyway, probably I haven't been clear on what the alternative I'm suggesting
is, so to clear that up I've pushed the patch at
https://github.com/pcmanus/cassandra/commits/5062-5 (on top of the last v4).
There is 4 commits in fact, but the important one is the first one only. As
you'll see, this still respect the invariant that "we don't start a new round
until we can guarantee that a quorum of replica have learned about the last
MRC", but if we can't prove that we have such a quorum, we repair nodes and
move on with the algorithm instead of throwing an exception.
The 2nd commit is just doing the "let's skip waiting on response once we got a
'not promised'", since that's trivial on top of the preceding patch. As for the
two last one, I wanted to check my "use the Commit class more generally" idea.
After having done it, I do think it make the clone slightly more readable, if
only because it allows to encapsulate better a few behavior in the Commit
class, because it avoid duplicating serialization code too much, and because it
removes PrepareRequest and ProposeRequest that are kind of uninteresting (and I
don't find that grouping things even for prepare is really making things
worth). But I'll agree to disagree if you still think it's a bad idea.
bq. Hmm, not sure where to fit this in.
Imo, the best option would be to have a 'paxos ttl' setting in the user CFs
like we have gc_grace. Then each write to the PaxosCF would use the value for
the CF this is an update of (i.e. not all row in PaxosCF would have the same
ttl if you don't same the same ttl in all of your CF, but that's ok).
One small concern might be that currently we share the same Paxos state for
rows belonging to different CF is they share the same key. But maybe that just
mean that we should stop doing that and include the cfId in the paxos sate row
key. After all, the API doesn't allow to do a CAS that span multiple CF anyway.
And I'm not convinced twisting the API to allow it is worth the trouble.
> Support CAS
> -----------
>
> Key: CASSANDRA-5062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Fix For: 2.0
>
> Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg,
> half-baked commit 3.jpg
>
>
> "Strong" consistency is not enough to prevent race conditions. The classic
> example is user account creation: we want to ensure usernames are unique, so
> we only want to signal account creation success if nobody else has created
> the account yet. But naive read-then-write allows clients to race and both
> think they have a green light to create.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
