Supporting optimistic locking would be easy and fast and doesn't come close to being a database (which must support pessimistic locking which is where all of the difficulty comes in).

The changes I'm talking about just involve having certain updates immediately fail. Nearly trivial changes that fundamentally change how reliably memcached can be used.

I believe it already has transactions for a single object always route to the same server where they are handled in a single-threaded manner. So there is very little left to fix.

I'm new to the concept of optimistic locking. The delete delay in memcached is a feature of delete command which allows specifying a delay during which all further adds, gets, replaces & deletes for this particular object which had been just deleted would fail. Does it look similar?

Anyway, I'm going to read about optimistic locks, they sound interesting.

Optimistic locking is useful for interfaces where you have a person interactively updating a record. You check out a copy of the record, give the user all the time in the world to work out what changes they want to make, then, when the user goes to apply the changes, if the record was changed after you checked out a copy, then you deny the update and force the user to start over. Those last steps need to be done atomicly which is usually where locks come into play. But just ensuring that update operations for any given record get processed one-at-a-time from a single queue will also make updates atomic.

To handle delete requests with this, you'd need to keep a place-holder for deleted records that consisted only of the revision number. I'd just let the external code decide what it wants to use as a place-holder for deleted records and use the update operation instead of the delete operation.

- tye