Ritesh, There don't seem to be any common best practices to do this. I think the reason is that by adding transaction semantics on top of Cassandra you're throwing away the most important properties of Cassandra. The effects of a transaction/locking layer:
- A centralized performance bottleneck that won't scale linearly - Complex failure detection and recovery - Reduced availability/partition tolerance (CAP: C prevents simultaneous A and P) - High latency for geographically remote clients - Lower throughput due to enforced serial ordering of transactions There are probably other reasons that didn't occur to me. Cassandra's great at doing what it does, but it's certainly not a general purpose transactional database for all use cases. -Dave On Wed, Feb 16, 2011 at 11:19 AM, tijoriwala.ritesh < tijoriwala.rit...@gmail.com> wrote: > > Hi Gaurav, > Thanks for the reply...I did look at the cages framework and I see that it > provides some functionality for locking and atomic writes for multiple > keys. > My question was that do people rely on these kind of frameworks - if so, is > cages the only one or are there others as well...and if not, what do they > do > to solve these kind of problems... > > Thanks, > Ritesh > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Patterns-for-writing-enterprise-applications-on-cassandra-tp6030077p6033138.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
