cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Kołaczkowski (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5062) Support CAS
Date Mon, 25 Feb 2013 22:02:18 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586346#comment-13586346
] 

Piotr Kołaczkowski edited comment on CASSANDRA-5062 at 2/25/13 10:02 PM:
-------------------------------------------------------------------------

I was thinking for using Paxos to do the CAS thing, not for leader election. For Paxos it
is advised not to use several parallel proposers only for performance reasons, not for correctness.
So it should be actually easier to implement than guaranteeing only one leader as you'd have
to do for 2PC or 3PC. 

I don't think using a lock-based protocol, assuming writes were at level < CL.ALL, is so
much simpler than Paxos. I have a feeling that if you start with an assumption that you need
to lock only quorum of replicas instead of all to perform an update, you'll immediately hit
all the same problems that led to inventing Paxos. 



                
      was (Author: pkolaczk):
    I was thinking for using Paxos to do the CAS thing, not for leader election. For Paxos
it is advised not to use several parallel proposers only for performance reasons, not for
correctness. So it should be actually easier to implement than guaranteeing only one leader
as you'd have to do for a lock-based protocol. IMHO considering that paxos seems simpler to
implement than 2PC or 3PC.

I don't think using a lock-based protocol, assuming writes at level < CL.ALL, is much simpler
than Paxos. I have a feeling that if you start with an assumption that you need to lock only
quorum of replicas instead of all to perform and update, you'll immediately hit all the same
problems that led to inventing Paxos.



                  
> 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

Mime
View raw message