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




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

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

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

          ### do your thing




Feedback welcome.




-------------- 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