incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Revell <>
Subject Re: Patterns for writing enterprise applications on cassandra
Date Wed, 16 Feb 2011 23:34:07 GMT
Re Anthony's statement:

> So it can be done and frameworks like CAGES are showing a way forward. At
> the heart of it, there will need to be a Two-Phase commit type protocol
> coordinator that sits in front of Cassandra. Of which - one can be sure -
> will be many implementations / best practices in the coming months.

I disagree. I think anyone who wants transactions should pick a database
that supports them. Bolting a transactional system on top could perhaps be
made to work at great cost if you always used CL ALL for every operation. I
personally don't think it's possible, but I can't actually prove it.

Consider how to enforce:
1) atomicity: you need some kind of undo/redo logging system with crash
recovery to handle partially-executed transactions. This is a lot of tricky
Cassandra-specific code. A locking system isn't good enough.
2) isolation: lock managers are f*&^ing hard, especially handling the
failure cases. Performant deadlock detection is difficult. Getting
sufficiently fine-grained locks would require Cassandra-specific code.

I'm trying to argue that these features belong inside the database, and not
bolted on top, so you should use a database that includes them.

Plainly: don't use Cassandra for applications that require
transactions. However, if you can express your app without the need of
transactions, that where Cassandra really shines.

+1 on Nate's recommendation to read the Helland paper.


On Wed, Feb 16, 2011 at 2:20 PM, Nate McCall <> wrote:

> I found the following paper (PDF) very helpful in shaping my thoughts
> about what it means to build systems without transactions.
> "LIfe Beyond Distributed Transactions: an Apostate's Opinion" by Pat
> Helland
> On Wed, Feb 16, 2011 at 2:00 PM, tijoriwala.ritesh
> <> wrote:
> >
> > Thanks a lot Anthony. That does help me think on possible options...
> > --
> > View this message in context:
> > Sent from the mailing list archive
> at
> >

View raw message