jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Haggood <codezi...@email.com>
Subject Re: OverlappingFileLockException using DerbyPersistenceManager
Date Thu, 10 May 2007 18:49:49 GMT
Any movement on this (apparently Linux-only) issue?  Checking a Sun
blogger I found the following note about 1.6 on Linux (and Sun) which
suggests that this behavior is what's SUPPOSED to happen, and not
blowing up on Windows is actually a mistake.


"Multiple locks on the same file

What does this code do? 
public class FileLock {
        public static void main(String[] args) throws Throwable {
            new FileOutputStream("foo").getChannel().lock();
            new FileOutputStream("foo").getChannel().lock();
Prior to Java SE 6, this code would deadlock on Microsoft Windows, and
return two locks on Linux and Solaris. Now, on all of those platforms,
the second lock attempt throws an OverlappingFileLockException, as
should have been the case all along since the behavior of lock() is
specified that way."

On Mon, 2007-02-26 at 10:26 +0100, Marcel Reutegger wrote:
> just my 2c, I didn't really investigated this issue in more detail...
> according to the javadoc of FileChannel.tryLock() the 
> OverlappingFileLockException is thrown if the JVM already holds a lock on the 
> channel.
> in contrast, the current check in the repository startup method primarily 
> focuses on the situation where *two* JVMs start a repository on the same home 
> directory.
> I'd say the OverlappingFileLockException is thrown because two repository 
> instances are startup within the *same* JVM using the same repository home 
> directory.
> I suggest we add a catch clause, which also covers OverlappingFileLockException 
> in addition to IOException.
> regards
>   marcel
> Stefan Guggisberg wrote:
> > btw, afaik OverlappingFileLockException is only thrown on linux,
> > FileChannel#getLock on windows e.g. returns null in the same situation.
> > 
> > you might want to test on a different platform to further isolate the 
> > issue.
> > you could also place a breakpoint at the top of the
> > RepositoryImpl#acquireRepositoryLock
> > method, step through the code, verify the contents of your fs etc.

View raw message