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

[Brian Burkhalter]

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/

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8166253
[2] http://mail.openjdk.java.net/pipermail/nio-dev/2016-November/003975.html
[3] https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileLock.html

On Nov 8, 2016, at 6:44 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> As for whether that's the most appropriate fix for the
> issue, then maybe the regular nio Reviewers will chime in :-)
> 
> best regards,
> 
> -- daniel
> 
> On 07/11/16 22:13, Brian Burkhalter wrote:
>> I have updated the patch to include the suggested changes:
>> 
>> http://cr.openjdk.java.net/~bpb/8166253/webrev.02/
>> 
>> The pertinent regression tests still pass.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180129/216b4a4f/attachment.html>