Atomic replace and append operations

Anatoly Vorobey mellon at
Sun Mar 20 03:25:11 PST 2005

On Sat, Mar 19, 2005 at 11:28:47PM +0000, Richard Cameron wrote:
> I'm making some good progress on this. I've added support for "append" 
> which was fairly straightforward and seems to work, as well as partial 
> support for "areplace" which still needs some more effort. I've also 
> patched libmemcache to let it speak these two commands.
> Aside from a few minor bits and pieces I need to do before releasing a 
> patch, the biggest issue I've got at the moment is that I can take a 
> clean, unhacked copy of memcached, run it up, and say:
> [set x "hello"]
> [delete x]
> very quickly followed by
> [add x "world"]
> I get a "NOT_STORED" error back. This is not what I'd expect to happen. 

This has been fixed in trunk some time ago. Please see
, note the log message on rev. 1.48.

Sorry you had to work on it and produce a patch (that works 
differently); it's only after reading your next message and trying to
apply your patch that I realised you weren't working with the trunk and
that this is the same problem we fixed back in July. I thought it might
have been something new.

> There are a few odd bits of code which look like they might 
> be covering up a more fundamental problem, for example:
>         if (old_it && (old_it->it_flags & ITEM_DELETED) && (comm == 
> NREAD_REPLACE || comm == NREAD_ADD)) {
>             out_string(c, "NOT_STORED");
>             break;
>         }

This code is correct; it's a feature for ADD/RESTORE to fail if the
item is in the DELETED state but is still linked (meaning it still
can be found by its key), which happens when you specify a non-null
expiration time to the DELETE command.

"There's nothing simply good, nor ill alone" -- John Donne

More information about the memcached mailing list