Revisiting NIO FileLock

[Charles Duffy <ch...@dyfis.net>]

Howdy --

In both the documentation and the code, the NIO FileLock implementation is
advised against. However, the open(O_CREAT|O_EXCL)-based system which is
presently used in favor of it has the major issue that locks are not
cleaned up on failures -- such that manual intervention can be required to
release stale locks in the event of a power loss, reboot, SIGKILL, or
similar event.

As such, I've revisited the NIO-based implementation, and found what is,
presumably, the bug which led to its deprecation: *The NIO-based mechanism,
as currently implemented on Ivy mainline, does not actually maintain locks
from tryLock() to unlock(), but rather grabs a lock only during the period
of time in which tryLock() is being executed.*
*
*
This is true because locks using the flock() and fcntl() mechanisms which
back NIO locks on UNIX live only as long as the file descriptors to which
they are attached, and tryLock() contains a finally block which closes the
file -- and thus closes the file descriptor, and thus releases the lock. I
have attached a patch fixing this issue to
https://issues.apache.org/jira/browse/IVY-1424.


There are cases where NIO locks will genuinely be less reliable than the
open(O_CREAT|O_EXCL) approach -- network filesystems without support for
flock(), for instance. However, when available and supported by the
underlying OS and filesystem, they should be considered the preferred
approach due to the operating system's enforcement of automated cleanup. As
such, I suggest making them available as a separate lock type, allowing the
local administrator to select the lock type appropriate to the operating
system on which they run, balancing the advantage of automatic cleanup
against the disadvantage of reduced portability.

Thoughts?