atomic get-then-delete command
mathias.herberts at gmail.com
Wed Apr 20 22:43:00 PDT 2005
it seems to me that a real consume command would need memcached to
have the ability to store different objects under the same key, that
is manage a real queue. Right now only one object can be stored under
a single key and that is one short message queue!
Or maybe use two additional keys, one for a produced counter, the
other for a consumed counter, and add the counter value to the name of
the queue to get a key for the next message to retrieve.
With a little tweaking I guess memcached could be turned into a poor man's MOM.
On 4/20/05, scott moody <conspyre at gmail.com> wrote:
> I'm completely new to memcached (and I'm happy to report that I've had
> no problems getting everything up-and-running). I know protocols
> aren't something one extends on a whim, but I was wondering if the
> addition of an atomic 'get-then-delete' command has ever been bandied
> about by anyone here. I would use such a command (which I refer to as
> a "consume" command) for memcached-based queues in order to implement
> non-persistent Linda/tuplespace/distributed computing patterns.
> My question is: Is such a command a bad idea for any reason? I ask
> because I cloned and then frankensteined the handler for the "get"
> command in memcached.c to create such a beast and it seems to be
> working okay thus far -- but I haven't programmed in C in nearly a
> dozen years and don't know the memcache code, so I'm certain that it's
> not a commercial-grade mod. However, it would seem to me that, because
> of the singled-threaded nature of memcached, it shouldn't a risky
> proposition. Am I wrong?
> Apologies for adding even more mail to your inbox,
More information about the memcached