cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Godás <dgo...@gmail.com>
Subject Re: Implementing a locking mechanism - RFC
Date Thu, 31 Jan 2013 12:33:32 GMT
Doesn't that require you to set up a server for the message queue and
know it's address? That sort of defeats the purpose of having a
database like cassandra in which all nodes are equal and there's no
single point of failure.

2013/1/31 Oleg Dulin <oleg.dulin@liquidanalytics.com>:
> Use a JMS message queue to send objects you want to write. Your writer process then will
listen on this queue and write to Cassandra. This ensures that all writes happen in an orderly
fashion, one batch at a time.
>
> I suggest ActiveMQ. It is easy to set up. This is what we use for this type of a use
case. No need to overcomplicate this with Cassandra.
>
>
> Regards,
> Oleg Dulin
> Please note my new office #: 732-917-0159
>
> On Jan 31, 2013, at 6:35 AM, Daniel Godás <dgodas@gmail.com> wrote:
>
>> Hi all,
>>
>> I need a locking mechanism on top of cassandra so that multiple
>> clients can protect a critical section. I've seen some attempts,
>> including Dominic Williams' wait chain algorithm but I think it can be
>> simplified. This is the procedure I wrote to implement a simple mutex.
>> Note that it hasn't been thoroughly tested and I have been using
>> cassandra for a very short time so I'd appreciate any comments on
>> obvious errors or things I'm doing plain wrong and will never work.
>>
>> The assumptions and requirements for the algorithm are the same as
>> Dominic Williams'
>> (http://media.fightmymonster.com/Shared/docs/Wait%20Chain%20Algorithm.pdf).
>>
>> We will create a column family for the locks referred to as "locks"
>> throughout this procedure. The column family contains two columns; an
>> identifier for the lock  which will also be the column key ("id") and
>> a counter ("c"). Throughout the procedure "my_lock_id" will be used as
>> the lock identifier. An arbitrary time-to-live value is required by
>> the algorithm. This value will be referred to as "t". Choosing an
>> appropriate value for "t" will be postponed until the algorithm is
>> deemed good.
>>
>> === begin procedure ===
>>
>> (A) When a client needs to access the critical section the following
>> steps are taken:
>>
>> --- begin ---
>>
>> 1) SELECT c FROM locks WHERE id = my_lock_id
>> 2) if c = 0 try to acquire the lock (B), else don't try (C)
>>
>> --- end ---
>>
>> (B) Try to acquire the lock:
>>
>> --- begin ---
>>
>> 1) UPDATE locks USING TTL t SET c = c + 1 WHERE id = my_lock_id
>> 2) SELECT c FROM locks WHERE id = my_lock_id
>> 3) if c = 1 we acquired the lock (D), else we didn't (C)
>>
>> --- end ---
>>
>> (C) Wait before re-trying:
>>
>> --- begin ---
>>
>> 1) sleep for a random time higher than t and start at (A) again
>>
>> --- end ---
>>
>> (D) Execute the critical section and release the lock:
>>
>> --- begin ---
>>
>> 1) start background thread that increments c with TTL = t every t / 2
>> interval (UPDATE locks USING TTL t SET c = c + 1 WHERE id =
>> my_lock_id)
>> 2) execute the critical section
>> 3) kill background thread
>> 4) DELETE * FROM locks WHERE id = my_lock_id
>>
>> --- end ---
>>
>> === end procedure ===
>>
>> Looking forward to read your comments,
>> Dan
>

Mime
View raw message