cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Morton <>
Subject Re: Implementing locks using cassandra only
Date Tue, 14 Sep 2010 01:13:11 GMT
Sorry, another thought was when storing in the Number CF how about using the the number as
the column name and the client ID as the column value. That way you could do a slice to get
the highest number, and the client can still assemble the hash of client_id to number. 


On 14 Sep, 2010,at 10:46 AM, Aaron Morton <> wrote:

Thanks for the post it looks really handy. I found this page to help my simple mind understand
whats going on 

 I've got some thoughts / questions mostly about implementation...

1. Any thoughts on how it would work with a dynamic number of clients? For example say I've
got a python web app, on 2 web servers each with 8 tornado web servers running which support
async IO. If I only every do sync IO to cassandra there will only every be 16 clients. If
a request uses async IO, it may yield and allow the web server to process another request
while it's waiting using another client connection.  

Could I use a TimeUUID as the client ID and replace max_clients with just the number of columns
in the Choosing CF? This may cause a problem with the loop at line 8, as it would potentially
change the count. Or use a TimeUUID as the client_id and just have a max_clients set suitable
high in config.

2. What about if you re-read the number_hash (as well as the choosing hash) when you detected
a client was choosing at line 9? This may be a little safer, as I guess the original algorithm
assumes the numbers array is shared memory. 

3. Your check at line 13 misses the comparison of the client id's as a tie breaker. Was this

4. Cassandra 0.7 has a TTL on the column values. Perhaps this could be used in the Numbers
and even the Choosing CF? Say give clients 1 second to get through their choosing section
and 10 seconds to get through their lock. 

 I've not read through the distributed work queue section yet, hope to later today.


On 14 Sep, 2010,at 05:50 AM, Jonathan Ellis <> wrote:

Bakery algorithm is really interesting -- AFAIK it's the only mutex
algorithm that doesn't assume an existing atomic operation like CAS.

On Mon, Sep 13, 2010 at 11:46 AM, Thorsten von Eicken
<> wrote:
> I've been musing about how to implement locks using just cassandra, i.e.
> without sql db or zookeeper. I wrote up what I've come up with on the wiki
> (it's a bit too long for an email) at
> <>. I'm wondering whether I've
> overlooked something, especially I'm not yet comfortable enough with the
> semantics of failing cassandra write operations to figure out whether these
> can cause problems, so I suspect some further iterations on the algorithm
> will be necessary.

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support

  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message