It seems pretty clear to me that the full memcached protocol is not appropriate for Cassandra. The question is whether some subset of it is of any use to anybody. The only advantage I can see is that there are a large number of clients out there that can speak it already; but any app that is making extensive use of it is probably doing so in a way that would preclude Cassandra+Jmemcached from being a "drop-in" addition.
Ryan On Mon, Apr 5, 2010 at 9:02 AM, David Strauss <da...@fourkitchens.com>wrote: > On 2010-04-05 07:47, Paul Prescod wrote: > > On Mon, Apr 5, 2010 at 12:01 AM, David Strauss <da...@fourkitchens.com> > wrote: > >> On 2010-04-05 03:42, Paul Prescod wrote: > >> ... > >> > >> There is a difference between Cassandra allowing inc/dec on values and > >> actually *knowing* the resultant value at the time of the write. It's > >> likely that inc/dec support will still feature blind writes if at all > >> possible. The memcached protocol returns a resultant value from inc/dec. > > > > Right. That's why I said that the proxy layer would need to read the > > result with an appropriate consistency level before returning to the > > memcached client application. The client application would need to > > declare its consistency preference using a configuration file. > > But your "write then read" model lacks the atomicity of the memcached > API. It's possible for two clients to read the same value. > > -- > David Strauss > | da...@fourkitchens.com > Four Kitchens > | http://fourkitchens.com > | +1 512 454 6659 [office] > | +1 512 870 8453 [direct] > >
