oh, CPAN, thou hast failed me

[mneme]

Less cryptically, why isn't there a perl-usable (pure perl or just something with perl wrappers; don't care) distributed locking system that's worth a damn? What's so hard to understand about "locks should only EVER be given out to one client, and clients need to know instantly if their locks become unreliable?" that causes everyone to get it wrong?

IPC::Lock::Memcache: memcache is a caching system, and may drop your locks on the floor without telling you; also, netsplit will hose you, also, dead clients don't auto-unlock=useless.

IPC::Locker: single-server (not ideal, but fine -- although it lets clients specify a group of machines that DON'T TALK TO ONE ANOTHER, which is worse than useless unless you -want- a high likelyhood of false locks), handles dead clients well via timeouts and checking for pid existence (though if pid server isn't working, probably can timeout longrunning locks while they're working = bad), but locks don't hold connections open. Which means if, say, your lock server reboots, instead of what -should- happen (all your processes holding open locks get signals and can decide this means they have to relock or dump all their work on the ground, as they no longer, well, have an exclusive lock), things go on happily having lost your lock. Checking for a lock before every atomic stage of a critical section? Not good.

Comments

[londo.livejournal.com]

I'd assume it's because that's worth money.

[mneme]

Possibly, though that's true for nearly every problem that gets an OSS solution -- the best criteria I've seen being that things that get an OSS solution are worth -more- money if you have a solution that just works and that you don't have to maintain than they are to build and try to sell.

In this case, it's clearly true; for most high availability systems, it's the systems that are worth a lot of money -- much more to the people running them than this would cost to develop for just -one- of them.

[avram]

On the other hand, it's also seems like the kind of thing that would scratch some programmer's itch, and those kinds of things are most likely to be well-served by the open-source community.

[stormsweeper.livejournal.com]

The trend in OSS is away from locking mechanisms entirely, I've found.

[jl8e]

Because distributed locking is hard?

[cattitude.livejournal.com]

Distributed locking is always inefficient; in high-level languages (like perl) it's unusably inefficient. If you need distributed locking, get a distributed database engine and let it do the locking for you. Call it using the usual perl/database bindings.