My 2 cents .. 1. Focus should be on the core problem Cassandra is solving i.e. Availability, Partitioning and a form of consistency that works (in spite of all the questions) . All this with high performance is a huge step forward - architecturally! 2. Any enhancement should shore up the core value proposition, should not detract from it. specifically, packing every feature into the product might create an easy to use kitchen sink, but also create a less nimble behemoth (not product names here ;)) 3. The beauty of open source is the ability to combine different ideas to solve a problem - with each piece (layer) providing an identified set of guarantees implemented with the greatest efficiency possible.
Finally, it will be a mistake to try drive Cassandra in the direction of an ACID data store, watering down the core value proposition. But I just talk! -JA On Thu, Feb 24, 2011 at 2:46 AM, tijoriwala.ritesh < tijoriwala.rit...@gmail.com> wrote: > > If it cannot protect against lost updates, isn't that an issue? How is > client > support to protect against concurrency? I see lot of users mentioning the > use of cages (i.e. use ZooKeeper) but involving locks on every writes at > the > application level is certainly not acceptable. And again, the application > will end up using vector clocks anyways. IMHO, this support should be built > into cassandra especially when it provides all the knobs to the client to > choose the right consistency level. So if client chooses R + W > N, then it > should be possible for Cassandra to detect conflicts. > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/New-Chain-for-Does-Cassandra-use-vector-clocks-tp6058892p6059594.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
