CODEWITHSUNDEEP
javafilelock
Hesey
Hesey

Reputation: 5257

Why one JVM get FileLock twice will throw OverlappingFileLockException?

Why get the FileLock twice in one JVM will throw OverlappingFileLockException? Why couldn't the second lock aquirement be blocked and get the lock when it released?

Upvotes: 0

Views: 1906

Answers (4)

volkerk
volkerk

Reputation: 140

Both the blocking lock() and non-blocking trylock() methods will throw OverlappingFileLockException "If a lock that overlaps the requested region is already held by this Java virtual machine, or if another thread is already blocked in this method and is attempting to lock an overlapping region of the same file", as documented in the FileChannel javadoc.

The reason is deadlock prevention. If another thread is already blocked while trying to acquire this lock, and you were to acquire this lock, you might next try to acquire some lock that this other thread is holding, leading to deadlock within the JVM. And if the lock you were trying to get is already held, you yourself might already be holding another lock that the other thread that's already holding this lock is trying to get, again leading to deadlock - so the exception is being thrown to make you aware of your potential coding error. If this happens when you call tryLock() you wouldn't be blocked, so won't have deadlock, but would likely get into an infinite loop of trying to acquire the lock. You need to acquire the locks always in the same order, then there won't be a chance of deadlock and you won't run into this, because no thread trying to acquire this lock will be blocked.

This implies that you mustn't do lock(), tryLock() in sequence for the same lock. If you got the lock already, you should remember that and mustn't request it again.

Note that if some other program is already holding this lock, no exception will be thrown and tryLock() will simply return null, whereas lock() will block until it can acquire the lock (i.e. the other program has unlocked the file region).

And no, this does not imply that tryLock() isn't thread safe. But it implies that you may need to catch and handle OverlappingFilelLockException in your code, even though that's not a declared exception.

Upvotes: 2

Mike Lee
Mike Lee

Reputation: 121

I am facing the same issue, this implies FileChannel.Lock/TryLock is not thread safe. And you are required to have synchronization over FileChannel lock in the same JVM. Either ReentranetLock or SingleThread confinement.

Upvotes: 0

Stephen C
Stephen C

Reputation: 718836

In fact, it is the method that you call to acquire a FileLock that determines whether the thread blocks or not:

  • FileChannel.lock(...) will block until the lock is acquired.
  • FileChannel.tryLock(...) will return immediately if the lock cannot be acquired.

Its all documented clearly in the FileChannel javadoc.

Incidentally, @glowcoder's stated reason is off track ... The "N" in NIO stands for New, not Non-blocking. Certainly, NIO supports both blocking and non-blocking I/O. (OK, maybe it was just a joke ... :-) )

Upvotes: 0

corsiKa
corsiKa

Reputation: 82579

Perhaps because it's in the NON BLOCKING IO package? :-)

It's a runtime exception which means technically it shouldn't ever happen in a production environment, only in development while detecting bugs.

Upvotes: 0

Related Questions