in reply to NFSLock - Continue in code if another server already has lock on file

Hi mightyMrJawz,

I could have up to 50 servers trying to determine if the file exists

To be honest, it really sounds like you need a database instead. Update: Note this quote from the File::NFSLock documentation: "Locks are not necessarily obtained on a first come first serve basis. Not only does this not seem fair to new processes trying to obtain a lock, but it may cause a process starvation condition on heavily locked files."

changed the code from "LOCK_EX" to "LOCK_NB"

AFAIK LOCK_NB is an option that is needed in addition to either LOCK_EX or LOCH_SH (Update: see also flock). See the example code at the top of File::NFSLock (I trimmed it down slightly):

use File::NFSLock; use Fcntl qw(LOCK_EX LOCK_NB); my $file = "somefile"; if (my $lock = new File::NFSLock { file => $file, lock_type => LOCK_EX|LOCK_NB, blocking_timeout => 10, # 10 sec stale_lock_timeout => 30 * 60, # 30 min }) { open(FILE, "+<$file") || die $!; # or open it any way you like # ... $lock->unlock(); }else{ die "I couldn't lock the file [$File::NFSLock::errstr]"; }

Instead of dieing, you would let your code continue.

BTW, there seems to be something wrong with the <code> tags in your post. Perhaps you could edit your node to fix that.

Hope this helps,
-- Hauke D

Replies are listed 'Best First'.
Re^2: NFSLock - Continue in code if another server already has lock on file (updated)
by mightyMrJawz (Novice) on Jan 12, 2017 at 17:43 UTC

    Thanks for the input haukex. Making the change you suggested seems to have resolved my issue. My assumption was that the lock_type was a singular input- which I now know was incorrect. For various reasons, a database wouldn't work well for my situation, and I'm not worried about a first come first serve basis. For the simple code change, I used:

    my $lock = new File::NFSLock ($datafile, LOCK_EX|LOCK_NB);