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