ecahill at corp.untd.com
Mon Sep 26 14:43:21 PDT 2005
Yeah, I can buy that. I can also buy that memcached on our system has
been live for nearly six months, has yet to have a problem, has
41,173,166 things currently cached across three boxes, and has handled
over 120 requests per second per box during that time. So yeah, it is a
simple cache thing, but I don't think I would have much of a problem
relying on it.
That said, maybe I could make a generic lock framework, and have
different drivers, like Lock::Memcached, Lock::mysql, Lock::Pg, or
whatever, where each driver would take a key name, provide a way of
doing something atomic, and a way to undo the atomic thing, like
add/delete for memcached.
Lock:: doesn't seem to exist on cpan. Any name space ideas?
From: Perrin Harkins [mailto:perrin at elem.com]
Sent: Monday, September 26, 2005 11:35 AM
To: Cahill, Earl
Cc: memcached at lists.danga.com
Subject: Re: Cache::Memcached::Lock
On Mon, 2005-09-26 at 09:29 -0700, Cahill, Earl wrote:
> Though it doesn't fully exist yet, I have been pondering writing a
> locking system built around memcached, and specifically the add
> method. I wrote such a system for my own use the other night, would
> like to generalize it a bit and would like to open source it. I would
> also like to pattern it around something open sourced from work to
> allow for locking over nfs, namely File::NFSLock
I've heard people say that File::lockf or Fcntl work for NFS locking. I
haven't tested them myself.
I'm sure memcached would be fast at this, but I wonder if it's a good
idea to store locks in a cache. Maybe a simple MySQL-based approach
would be safer.
More information about the memcached