[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588596#comment-13588596
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
Let me first say that as far as I'm concerned, the priorities for this ticket
should be:
# correctness (as in, it would be nice not to spend the next 4 years fixing
corner cases).
# an implementation that doesn't make Cassandra's code some Frankenstein
monster.
You'll note that being fast is not on this list. That doesn't mean I don't care
about fast, all other things being equal, faster is better. But I don't think
we're targeting heavy use of conflicting CAS, not at first at least. The
typical use case we're targeting initially is the one described by Jonathan,
the unique user account creation problem. In that use case, 1) your application
probably don't do much user creation check (comparated to the overall cluster
load at least) and 2) it's fairly easy to partition the problem so that your
CAS will rarely conflict (so Paxos failing at liveness is not a huge concern).
All that to say that I'd rather start with something as simple as possible, and
consider optimisations later (as Jonathan said, if we expose this as a CAS, we
can switch the implementation later if need be).
Now, for our use case, I do believe Paxos without optimisation (that does mean
one complete paxos per-CAS) is simpler than Zab (to be honest, I haven't look
that much at Zab, but what I've seen does seem more complicated in practice).
I'm aware of papers like
http://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/paper2-1.pdf but their
main difficulties are due to 1) multi-paxos (not what I'm suggesting) and 2)
replicated log grow (it's difficult for them for reasons that don't apply to us
(we fully control the data to which the replicated log applies)). Could be that
I'm over-optimistic but...
Anyway, all that to say that I'm going to give a shot at prototyping a version
with a simple Paxos. I've tried to detail a concrete implementation a bit on
paper and that doesn't sound too bad, we'll see. But feel free to give a shot
to Zab and see how that goes :)
That does lead me to a more mundane problem: how do we expose a CAS in CQL3
(thrift is simpler as it happens)?
> 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
>
>
> "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
