Cache::Memcached::Lock

[Perrin Harkins]

On Tue, 2005-09-27 at 13:21 -0700, Cahill, Earl wrote:
> I think some of the concern comes from Cache being in the name of
> Cache::Memcache.  I guess my question is, when can you trust Memcached?
> Like, can I trust the ttl?  Is add really atomic?  If I set x=y, do I
> get x=y back?  If yes to those three things, then Memcached seems a good
> candidate for my project.

Well, the answer is "maybe."  If you set x=y and then the server holding
x goes down, or runs out of space, you may not get y back.

My questions to determine suitability would be:

- If all the data I put in suddenly disappeared, would that be a
problem?
- If some of the data disappeared and I didn't know which data or even
that anything had happened, would that be a problem?  (You could hack
the client lib to tell you when you lost a server, but I don't think
anyone has.)
- If memcached ran out of free memory and silently dropped pieces of
data that I had given it, would that be a problem?

If the answer to any of these is yes, consider your alternatives.  For a
true cache application, the answer to all of these should be no.

> I don't really want data to
> randomly change or disappear.  But in my experience, it doesn't.

I hear you, but this is like saying "I've never had a hard drive
failure, so what do I need these backups for?"  These losses WILL happen
if the server runs out of memory or the daemon stops running for any
reason (hardware glitch, bug in some C code, sysadmin mistake, etc.).  I
think this could even happen if your network went out briefly and the
client couldn't reach the memcached server.

> Some concerns seem a touch FUD-ish.

You're free to do whatever you like with your own NFS server.  You may
decide that the potential for data loss is no worse than you would have
with the alternatives anyway.  What worries me is when people start
saying "Hey, I have this awesomely fast session storage system!" or
something similar, and don't mention the risks involved.  I'm all for
letting people choose how much risk they can handle in a particular
application, but they should know what they're getting into.

- Perrin