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?
