Jonathan, thanks for this pointer. I've new had a look at contrib/mutex. Coming back to my point, the use of Zookeeper within Cassandra for the purpose of then being able to deliver a "unique key generation function" out of Cassandra seems like overkill, in this case the application could use Zookeeper directly to accomplish this task.
However, I think we're already more than half-way without Zookeeper: the problem is, that after the "concurrent" insert, both reads might try to repair in the opposite direction, thus the inconsistency is not deleted but rather only turned upside down. This could be prevented by introduction of a tie-breaker. Imagine the following rule: if we are in doubt whether to repair a column with timestamp T (because two values X and Y are present within the cluster, both at timestamp T), then we always repair towards X if md5(X)<md5(Y). In this case, even after an inconsistency on the first insert, this would be cleared by any node that triggers a repair afterwards. And then you're done: a Cassandra can create a unique transaction ID by inserting a column with the ID this clients wants to grab as key, and some random stuff as value, then the clients reads the just inserted column, and if the ID and the same random stuff is there - voila, the ID is unique for this client. -Roland 2010/4/29 Jonathan Ellis <jbel...@gmail.com> > 2010/4/28 Roland Hänel <rol...@haenel.me>: > > Thanks Jonathan, that hits exactly the heart of my question. > Unfortunately > > it kills my original idea to implement a "unique transaction identifier > > creation algorithm" - for this, even eventual consistency would be > > sufficient, but I would need to know if I am consistent at the time of a > > read request. > > right, for that kind of thing you'd really want to use contrib/mutex > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
