Using the lock verifier above, I discovered something shocking (to
me): NativeFSLockFactory is in general NOT RELIABLE for locking over
NFS, while SimpleFSLockFactory is reliable modulo the "fails to delete
on exit/crash" minor issue.
This is unexpected because the whole reason we originally created
NativeFSLockFactory was to improve locking over "challenging"
filesystems like NFS. The spooky comment in Sun's javadocs on using
File.createNewFile for locking (which is what SimpleFSLockFactory
uses) drove this:
But then I remembered Marvin's comment about this:
And on following that lead, indeed, that comment "Note: this method
should not be used for file-locking, as the resulting protocol cannot
be made to work reliably" is only referring to the fact that you
cannot reliably guarantee this lock file will be properly removed.
In testing in my NFS area (mix of Linux & OS X), I see
NativeFSLockFactory sometimes (rarely) allowing a lock to be
double-acquired. Whereas after stress testing SimpleFSLockFactory for
a looong time, it never allows that.
So the NFS challenge/saga continues: now, you should in fact use
SimpleFSLockFactory, and work around the fact that you will sometimes
have to manually remove lock files (it is the lesser of evils).