cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremiah Jordan <jeremiah.jor...@morningstar.com>
Subject Re: How to reliably achieve unique constraints with Cassandra?
Date Fri, 06 Jan 2012 20:53:21 GMT
Correct, any kind of locking in Cassandra requires clocks that are in 
sync, and requires you to wait "possible clock out of sync time" before 
reading to check if you got the lock, to prevent the issue you describe 
below.

There was a pretty detailed discussion of locking with only Cassandra a 
month or so back on this list.

-Jeremiah

On 01/06/2012 02:42 PM, Bryce Allen wrote:
> On Fri, 6 Jan 2012 10:38:17 -0800
> Mohit Anchlia<mohitanchlia@gmail.com>  wrote:
>> It could be as simple as reading before writing to make sure that
>> email doesn't exist. But I think you are looking at how to handle 2
>> concurrent requests for same email? Only way I can think of is:
>>
>> 1) Create new CF say tracker
>> 2) write email and time uuid to CF tracker
>> 3) read from CF tracker
>> 4) if you find a row other than yours then wait and read again from
>> tracker after few ms
>> 5) read from USER CF
>> 6) write if no rows in USER CF
>> 7) delete from tracker
>>
>> Please note you might have to modify this logic a little bit, but this
>> should give you some ideas of how to approach this problem without
>> locking.
> Distributed locking is pretty subtle; I haven't seen a correct solution
> that uses just Cassandra, even with QUORUM read/write. I suspect it's
> not possible.
>
> With the above proposal, in step 4 two processes could both have
> inserted an entry in the tracker before either gets a chance to check,
> so you need a way to order the requests. I don't think the timestamp
> works for ordering, because it's set by the client (even the internal
> timestamp is set by the client), and will likely be different from
> when the data is actually committed and available to read by other
> clients.
>
> For example:
>
> * At time 0ms, client 1 starts insert of user@example.org
> * At time 1ms, client 2 also starts insert for user@example.org
> * At time 2ms, client 2 data is committed
> * At time 3ms, client 2 reads tracker and sees that it's the only one,
>    so enters the critical section
> * At time 4ms, client 1 data is committed
> * At time 5ms, client 2 reads tracker, and sees that is not the only
>    one, but since it has the lowest timestamp (0ms vs 1ms), it enters
>    the critical section.
>
> I don't think Cassandra counters work for ordering either.
>
> This approach is similar to the Zookeeper lock recipe:
> http://zookeeper.apache.org/doc/current/recipes.html#sc_recipes_Locks
> but zookeeper has sequence nodes, which provide a consistent way of
> ordering the requests. Zookeeper also avoids the busy waiting.
>
> I'd be happy to be proven wrong. But even if it is possible, if it
> involves a lot of complexity and busy waiting it's probably not worth
> it. There's a reason people are using Zookeeper with Cassandra.
>
> -Bryce

Mime
View raw message