Dave, I agree with you, mostly ;) !!
While the reference to 2PC is a tad misplaced here - the idea is that the paradigm of transactions might have to get redefined or - better still - broadened to include protocols that the provide similar guarantees in an eventually consistent dispensation. Bottom line - just like eventual consistency takes getting used to and absorbed - we will figure out ways to write applications that require transactions (per current definition) against a datastore that does not strictly support it. Again, remember the current notion of transaction (historically speaking) came after practice of transaction processing. One can think of many ways to doing this, but no point in bloviating without having something to show. HTH, -JA On Wed, Feb 16, 2011 at 5:34 PM, Dave Revell <d...@meebo-inc.com> wrote: > 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 - > there > > 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. > > Contentiously, > Dave > > On Wed, Feb 16, 2011 at 2:20 PM, Nate McCall <n...@datastax.com> wrote: > >> I found the following paper (PDF) very helpful in shaping my thoughts >> about what it means to build systems without transactions. >> >> http://www.ics.uci.edu/~cs223/papers/cidr07p15.pdf >> >> "LIfe Beyond Distributed Transactions: an Apostate's Opinion" by Pat >> Helland >> >> On Wed, Feb 16, 2011 at 2:00 PM, tijoriwala.ritesh >> <tijoriwala.rit...@gmail.com> wrote: >> > >> > Thanks a lot Anthony. That does help me think on possible options... >> > -- >> > View this message in context: >> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Patterns-for-writing-enterprise-applications-on-cassandra-tp6030077p6033316.html >> > Sent from the cassandra-u...@incubator.apache.org mailing list archive >> at Nabble.com. >> > >> > >
