IPC::Lock::Memcached

Cahill, Earl ecahill at corp.untd.com
Fri Oct 21 10:20:49 PDT 2005


Last night I wrote IPC::Lock and IPC::Lock::Memcached.  They are here

 

http://search.cpan.org/~earl/IPC-Lock-0.10/

 

Yes, it wasn't real hard, and mostly a wrapper around memcached's
add/delete functions.  I tried to write so that other drivers could be
written so long as there was a function that was atomic, like a db
insert.  That just gets a little messier, since you need a table, and
the ttl stuff gets a little trickier since I don't know of a way to
autoexpire in a db.

 

I will likely write IPC::Lock::DB, which will require you to pass in a
dbh, and then do the rest for you.  I can't really see too many
differences between mysql, postgres, oracle or any db that allows for
temporary tables, has an atomic insert, and is say ansi 92 compliant.  I
will likely ensure that a temporary table exists on instantiation, then
use that table for locking.  But alas, this is the memcached list.

 

Really, about all that IPC::Lock::Memcached buys you is that if the add
fails, it will try for $self->{patience} seconds and pause
$self->{increment} seconds between each try.  That and it automatically
unlocks when your lock object leaves scope.  

 

>From the IPC::Lock::Memcached perldoc, usage looks like this

 

{

      my $lock = IPC::Lock::Memcached->new({

          memcached_servers => ['localhost:11211'],

      });

      ### following memcached tradition, spaces aren't allow in the key
name

      ### and the user is expected to check such things themselves

      if($lock->lock('magic_key')) {

          ### do your thing

      }

}

 

Feedback welcome.

 

Thanks,

Earl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20051021/cc1b33f3/attachment.htm


More information about the memcached mailing list