cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Perroud <ben...@noisette.ch>
Subject Re: Usage Pattern : &quot;unique&quot; value of a key.
Date Thu, 13 Jan 2011 11:00:45 GMT
Thanks for your answer.

You're right when you say it's unlikely that 2 threads have the same
timestamp, but it can. So it could work for user creation, but maybe
not on a more write intensive problem.

Moreover, we cannot rely on fully time synchronized node in the
cluster (but on node synchronized at a few ms), so a second node could
theoretically write a smaller timestamp after the first node.
An even worst case could be the one illustrated here
(http://noisette.ch/cassandra/cassandra_unique_key_pattern.png) :
nodes are synchronized, but something goes wrong (slow) during the
write, then both nodes think the key belongs to them.
So my idea of writing a lock is not well suitable...
Does anyone have another idea to share regarding this topic ?

Thanks,

Kind regards,

Benoit.

2011/1/13 Oleg Anastasyev <oleganas@gmail.com>:
> Benoit Perroud <benoit <at> noisette.ch> writes:
>
>>
>> My idea to solve such use case is to have both thread writing the
>> username, but with a colum like "lock-<RANDOM VALUE>", and then read
>> the row, and find out if the first lock column appearing belong to the
>> thread. If this is the case, it can continue the process, otherwise it
>> has been preempted by another thread.
>
> This looks ok for this task. As an alternative you can avoid creating extra
> \lock-random value' column and compare timestamps of new user data you just
> written. It is unlikely that both racing threads will have exactly the same
> microsecond timestamp at the moment of creating a new user - so if data you read
> have exactly the same timestamp you used to write data - this is your data.
>
> Another possible way is to use some external lock coordinator, eg zookeeper.
> Although for this task it looks a bit overkill, but this can become even more
> valuable, if you have more data concurrency issues to solve and can bear extra
> 5-10ms update operations latency.
>
>

Mime
View raw message