Java File Locking Mechanism for File Based Process Communication

Java file locking mechanism for file based process communication

Maybe this class can help you http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html

Edit: This post might already be covering the subject How can I lock a file using java (if possible)

Exemple:

FileInputStream in = new FileInputStream(file);
try
{
    java.nio.channels.FileLock lock = in.getChannel().lock();
    try
    {
        //write
    }
    finally
    {
        lock.release();
    }
}
finally 
{
    in.close();
}

Now in the reading process:

FileInputStream in = new FileInputStream(file);
try
{
    FileLock lock = in.getChannel().tryLock();
    if (lock == null)
    {
        //file is locked, wait or do something else
    }
    else
    {
        try
        {
            //read
        }
        finally
        {
            lock.release();
        }
    }
}
finally 
{
    in.close();
}

Inter-process file locking in Java

try (RandomAccessFile raf = new RandomAccessFile(file, "rw")) {
    while (raf.getChannel().tryLock() == null) {
        Thread.sleep(10);
    }
    // lock acquired
}

The lock will be automatically released (indirectly - via closing the RandomAccessFile) by the try-with-resurces block.

BTW the OverlappingFileLockException is thrown because the current JVM already has the lock, or a thread of the current JVM is already waiting for it.

Unable to lock files on Linux using java.nio.channels.FileLock

I used same sample as you and got same problem on Mac OS X. It seems that file lock does not prevent file deletion on POSIX systems . Your app wil still have some kind of handle to that file until you unlock it. So consider using lock file with PID in it's name( or inside file).

java io read and write lock

You'll need to devise your own locking protocol to implement in the applications. Specifics depend on the underlying operating system, but in general, nothing will stop one process from reading a file even when another process is writing to it.

Java has a FileLock class that can be used to coordinate access to a file. However, you'll need to read the caveats carefully, especially those relating to the system-dependence of this feature. Testing the feature on the target operating system is extremely important.

A key concept of Java's FileLock is that it is only "advisory". Your process should be able to detect that another process holds a lock on a file, but your process can ignore it and do what it likes with the file, no restrictions.

The question is ambiguous whether multiple process will use the file, or merely separate threads within a single Java process. That's a big difference. If the problem requires only thread safety within a single process, a ReentrantReadWriteLock can provide a robust, high performance solution, without any platform-specific pitfalls.

Java/Unix: Can a Process sucessfully write a File if another Process tries to reads it inbetween

1. Will Process A be able to successfully write the file to disk, even if Process B tries to read?

Yes. It will be able to write the file correctly. Reads do not interfere with a write ... on Linux.

2. What happens in Process B ? is the file locked? is there an IOException thrown? or can it read the incomplete file?

It will probably see an incomplete file. (It might see a complete file ... if you are lucky.)

Linux doesn't lock files by default. To get locking, both the reader and the writer need to make flock(2) syscalls. In Java that maps to using FileLock.

No Java IOException will be thrown on UNIX / Linux / MacOS. (Or on Android.) You will only run into locking issues on Windows.

---

Any hints appreciated.

Hint: you could just write a little test program and try it ....

Java FileLock issues on Linux NFS

I found the root cause of this issue. It seems that when two different threads of the same JVM create a RandomAccessFile object on the same file, calling RandomAccessFile.close from one thread, releases the lock the other thread has.

The documentation of RandomAccessFile.close says

Closes this random access file stream and releases any system resources associated with the stream.

I'm not sure if this means that the system resources are released on the JVM level. I would expect that each RandomAccessFile object would get its own stream and release only that one but it seems that is not the case (or at least the lock on that file gets released. Note that this behavior has not been observed on Windows systems.

---

Related Topics