[9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock

[Alan Bateman]

On 30/01/2018 01:23, Brian Burkhalter wrote:
> This is a continuation of the discussion about [1] which trailed off 
> with [2].
>
> According to [3]:
>
> "A file-lock object is initially valid. It remains valid until the 
> lock is released by invoking the release method, by closing the 
> channel that was used to acquire it, or by the termination of the Java 
> virtual machine, whichever comes first."
>
> The problem described in the issue occurs when a FileLock is obtained 
> and subsequently becomes unreachable and is collected before the 
> underlying native lock has been released (either explicitly or by 
> closing the channel). In this case an attempt to obtain an overlapping 
> lock should still be rejected in order to satisfy the foregoing 
> specification, namely “[…] or by the termination of the Java virtual 
> machine.”
>
> The proposed fix is:
>
> http://cr.openjdk.java.net/~bpb/8166253/webrev.03/ 
> <http://cr.openjdk.java.net/%7Ebpb/8166253/webrev.03/>
>
I think it would be simpler if FileChannel maintained a set of the valid 
locks obtained via the channel, the the unlock can remove the lock from 
the set.

While in the area then I think we can drop SimpleFileLockTable - that 
was for 1.4/1.5 era compatibility (enabled via the 
sun.nio.ch.disableSystemWideOverlappingFileLockCheck system property) 
and I can't imagine anything dependent on this broken behavior in 2018.

-Alan