- 
    Bug 
- 
    Resolution: Fixed
- 
     P4 P4
- 
    8, 9
- 
        b01
- 
        generic
- 
        generic
- 
        Verified
                    FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
When a FileLock obtained from a FileChannel gets GC'd (garbage collect'd) the underlying file lock is released. This behavior is very surprising. Since a developer normally wouldn't expect the need to maintain a reference to the obtained FileLock object himself/herself and may easily assume the reference is maintained automatically in the FileChannel object.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the code attached. See code-level documentation for more detail.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Throw an OverlappingFileLockException.
ACTUAL -
File lock released unexpectedly. No OverlappingFileLockException thrown.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.RandomAccessFile;
public class FileLockBug {
/**
* This class demonstrates a bug in which a FileLock object gets GC'd
* and results in unexpected release of the file lock.
*/
public static void main(String[] args) throws Exception {
        
final File f = new File("/tmp/file");
final RandomAccessFile raf1 = new RandomAccessFile(f, "rw");
// acquire an exclusive lock
// the returned FileLock has no reference to it
// (candidate for GC)
raf1.getChannel().tryLock();
// force GC and remove the FileLock object created above
System.gc();
final RandomAccessFile raf2 = new RandomAccessFile(f, "rw");
// expected: an OverlappingFileLockException
// (since a lock has already been acquired on the same file)
// actual: lock acquired successfully due to this bug
raf2.getChannel().tryLock();
raf2.close();
raf1.close();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Always maintain a reference of the FileLock obtained to avoid it being GC'd.
For example:
FileLock fileLock = randomAccessFile.getChannel().tryLock();
...as opposed to
randomAccessFile.getChannel().tryLock();
            
A DESCRIPTION OF THE PROBLEM :
When a FileLock obtained from a FileChannel gets GC'd (garbage collect'd) the underlying file lock is released. This behavior is very surprising. Since a developer normally wouldn't expect the need to maintain a reference to the obtained FileLock object himself/herself and may easily assume the reference is maintained automatically in the FileChannel object.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the code attached. See code-level documentation for more detail.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Throw an OverlappingFileLockException.
ACTUAL -
File lock released unexpectedly. No OverlappingFileLockException thrown.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.RandomAccessFile;
public class FileLockBug {
/**
* This class demonstrates a bug in which a FileLock object gets GC'd
* and results in unexpected release of the file lock.
*/
public static void main(String[] args) throws Exception {
final File f = new File("/tmp/file");
final RandomAccessFile raf1 = new RandomAccessFile(f, "rw");
// acquire an exclusive lock
// the returned FileLock has no reference to it
// (candidate for GC)
raf1.getChannel().tryLock();
// force GC and remove the FileLock object created above
System.gc();
final RandomAccessFile raf2 = new RandomAccessFile(f, "rw");
// expected: an OverlappingFileLockException
// (since a lock has already been acquired on the same file)
// actual: lock acquired successfully due to this bug
raf2.getChannel().tryLock();
raf2.close();
raf1.close();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Always maintain a reference of the FileLock obtained to avoid it being GC'd.
For example:
FileLock fileLock = randomAccessFile.getChannel().tryLock();
...as opposed to
randomAccessFile.getChannel().tryLock();
