Whether or not it can be made to work, it seems a poor fit for Cassandra. Why not use Zookeeper?
On Sun, Mar 14, 2010 at 9:46 AM, Toby DiPasquale <t...@cbcg.net> wrote: > Hi all, > > I'm trying to write an application using Cassandra which requires the > use of a global, monotonically-increasing counter. I've seen the > previous threads on this subject which basically say that this can't > be done in Cassandra as is, but I think I've come up with a method > that might work. I wanted to get the list's feedback on whether or not > this method is workable: > > * Each client maintains its own monotonically-increasing counter as a > row in Cassandra > * When a client wants to increment the counter, it will: > * increment its own counter key using a quorum write > * read all keys in the CF using a quorum read > * the sum of the values is then the value of the counter > > This method is robust against nodes coming and going (new nodes just > get a new counter and dead nodes never increase their counter again). > It also doesn't matter for my application if some possible values for > the counter are skipped over, as long as every value is greater than > the last. I believe this scheme to be commensurate to a vector clock, > no? > > My question would be: assuming we're using both quorum reads and > writes, is it possible that clients A and B could race in the > following manner: > > * A updates its counter > * B updates its counter > * A reads the keys to get sum X > * B reads the keys to get the same sum X > > ...thus violating the ever-increasing constraint? > > Google App Engine suggests a similar method for doing global counters > on Datastore: > http://code.google.com/appengine/articles/sharding_counters.html. > I'm troubled by their implementation, though, because the reads on the > list of counters are not transactional and are potentially subject to > the same race that I've described above. > > Any thoughts/ideas? > > -- > Toby DiPasquale >
