File::NFSLock owner identification?

[SleepyJay]

I have a File::NFSLock issue that goes something like...

Two (or more) servers with shared NFS space both get a request to run some process. They both try to write an NFSLock. Due to timing issues, they could BOTH think they have the lock. Obviously, only one *really* has the lock, but as far as I can tell, you can't actually know which one does. So, they both run the process, even though only one needs to. The results of the process comes out correctly, but the issue is only that both servers run the process when one would suffice. Of course, once the lock is established, future requests are locked out in the correct way until the lock is released.

I was thinking that if a server could identify which one actually got the lock, at some point during the running process, it could periodically check if it were the owner of the lock. If it wasn't, it could gracefully stop the process and assume the one with the lock would finish correctly. Is there some reasonable way to do that?

I guess I mean it would need to write some extra metadata into the lock that it could retrieve to identify the actual "owner".

I'm sorry, I meant to say, that I have read the File::NFSLock documentation and there is no mention of being able to arbitrarily stuff data into it. I just meant if anyone had any other ideas on how to tackle this problem. Maybe I'm just posting here in the hopes someone has something enlightening and uplifting to say! :)

[wazat]

I haven't personally used File::NFSLock, but from what I read in the docs, if you request an exclusive lock, only one process will get the lock. The other process may block until the lock becomes free, or until a specified time has passed. If the time passes before the lock becomes free, the return lock will be undef.

The example included in the module documentation,seems understandable.

http://search.cpan.org/~bbb/File-NFSLock-1.21/lib/File/NFSLock.pm

However not having used this module, I can only assume that it works as advertised. Are you aware of anything to the contrary?

[taint]

Greetings, Sleepyjay

I think it might be worth noting, that it would probably be more advantageous if you were to share what OS the server(s) are running. Things have changed over the years in NFS, and not equally among all OS's. Perhaps more importantly; the module ( File::NFSLock ) you refer to is actually quite old. I know for a fact, that NFS has changed dramatically since 2003. This may well explain the unusual behavior you're experiencing.

Best wishes.

--Chris

[Anonymous Monk]

This may well explain the unusual behavior you're experiencing.

Unlikely, the fundamentals of NFS haven't changed

[taint]

They have, in fact. Quite a bit, since 2003. NSF4, in fact didn't even exist in 2003.

The locking mechanism, has also been modified, in both *BSD, and Linux. I am aware of this, as I'm subscribed to the development lists on both.

--Chris

[Anonymous Monk]

They both try to write an NFSLock. Due to timing issues, they could BOTH think they have the lock.

Not likely. One will get the lock, the other won't, they both can't get a lock, one will always fail, and if it fails to get a lock, it should quit.

[taint]

Definitely true of the OS. But what of the module? Does a thread in the module think it has a lock? Or possibly some other anomaly within the module itself?

--Chris

[Anonymous Monk]

Definitely true of the OS. But what of the module? Does a thread in the module think it has a lock? Or possibly some other anomaly within the module itself?

Incomprehensible