cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5062) Support CAS
Date Tue, 09 Apr 2013 14:44:16 GMT


Jonathan Ellis commented on CASSANDRA-5062:

bq. in other words, the current algorithm does not do Paxos at the row level, but rather paxos
at the level of all rows whose key's hashcode modulo 1024 is equal, and 2 proposers on 2 different
row keys may compete with each other.

Agreed, but what are you proposing as an alternative?  Allocating a lock per row would be
madness, and attempting to write it without locks looks very difficult.

(I will note that the contention is probably not that bad, since the two rows would have to
hash to the same lock across a majority of replicas, which in a vnode world is unlikely.)

bq. this in turn means that we'll timeout as soon as any node that we though were alive happens
to be dead, even if we have a QUORUM of responses

Not so -- we will wait for it, but when it does not reply we will be able to continue as long
as the nodes that did reply constitute a quorum.  (I.e., we check responseCount vs requiredParticipants,
not vs endpoints.size().)

bq. Can't we just say in PrepareCallback that if promised != true for a response, then we
do a 'while (latch.getCount() > 0) latch.countDown()'?

Sure, but then we have to add special cases back up to avoid throwing UAE, or move the promise
check into PrepareCallback and have it throw a control-flow exception, neither of which appeals
to me.

bq. I think we want to guarantee that the column timestamp resolution won't break that order

You're right, this could get ugly with HH, RR, etc.
> Support CAS
> -----------
>                 Key: CASSANDRA-5062
>                 URL:
>             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
> "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:

View raw message