On Sun, Apr 4, 2010 at 2:13 PM, Ryan Daum <r...@thimbleware.com> wrote: > > I'm the author/maintainer of jmemcached; I'd be willing to do this and it'd > be quite easy to do, but Cassandra is missing a number of things which would > make it so we could only support a subset of the memcache protocol.
Yes, I had presumed that I would need to give up on the various functions that depended upon the previous value being available. The only one of these that I use in my applications is "add", to use Memcached as a hacky lock server. I'm willing to give that up though: there are many other components like Zookeeper and MySQL that can do locking. As soon as you have more than one Memcached server and a risk of partition, you already start to run into issues with depending on previous memcached values being "correct". So I'd propose you implement the subset for now. I have another idea about how to handle the longer term issue, though. My understanding of http://issues.apache.org/jira/browse/CASSANDRA-580 is that it will allow writes that are meant to be "merged" with other writes, like appends, increments and conditional sets. If I understand it correctly, you would register six "handlers" for increment, decrement, append text, prepend text, set-if-nonexistent, set-if-old-value-is-the-same. Vector clocks are slated to be implemented in Cassandra 0.7 In order to strictly implement Memcached behaviour (where the result is returned immediately), you'd need to do a READ just after your WRITE, to force the conflict engine to detect and resolve the conflict. A configuration file would probably allow the end-user to determine how slow/consistent this read should be: * http://wiki.apache.org/cassandra/API#ConsistencyLevel If you use memcached's clustering technique, rather than cassandra's, then all consistency levels would be equivalent. If there were a race condition in a multi-node situation (two writes before the nodes were consistent), probably both clients would have their writes rejected. They could either continue on that basis or retry with exponential back-off. > ... > > that said, if people see a use case for this, I would do it. I personally think that it would hit a nice 80/20 point, and once vector clocks are implemented it might be easy to get to 99% memcached compatibility. Paul Prescod
