jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-933) RepositoryImpl.acquireRepositoryLock() fails to detect that the file lock is already held by the current process
Date Thu, 24 May 2007 02:44:16 GMT

     [ https://issues.apache.org/jira/browse/JCR-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jukka Zitting updated JCR-933:

    Attachment: RepositoryLock.patch

Clever! Using a synchronized interned system property feels icky, but it actually achieves
the required functionality.

The repository lock mechanism has accumulated a lot of collective knowledge and already contains
> 50 LOC, so I guess it would make sense to refactor it into a separate helper class. Especially
given the already large size of the RepositoryImpl class. The attached patch (RepositoryLock.patch)
contains Stefan's suggested fix and refactors all the repository lock code into a separate
o.a.j.core.util.RepositoryLock class. I also added a bunch of javadocs and tests.

The RepositoryLock class should be mostly equivalent to the current code + Stefan's fix. I
made the following functional changes to streamline the code:

* Removed the extra call to File.createNewFile() since creating the RandomAccessFile instance
with mode "rw" will automatically create the file
* Canonicalized the path names once at the beginning
* Renamed and reorganized variables to make the code appear more like a generic directory
locking tool

> RepositoryImpl.acquireRepositoryLock() fails to detect that the file lock is already
held by the current process
> ----------------------------------------------------------------------------------------------------------------
>                 Key: JCR-933
>                 URL: https://issues.apache.org/jira/browse/JCR-933
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>         Environment: java 1.4 & 1.5 on *nix-based platforms.
> (verfied with java 1.4 on mac os-x 10.4.9) 
>            Reporter: Stefan Guggisberg
>         Assigned To: Stefan Guggisberg
>            Priority: Critical
>             Fix For: 1.3.1
>         Attachments: jcr-933.patch, RepositoryLock.patch
> with java 1.4 and 1.5 on a *nix-based platform it is possible to (concurrently) instantiate

> more than one repository instance in the same jvm based on same/identical configurations.
> this is a critical issue since it might lead to data corruption.
> the issue only exists with java versions prior to 1.6 and *nix-based platforms (only
> on mac os-x 10.4).
> note that the issue does not exist when the file lock is held by another jvm.
>  code snippet to reproduce the issue:
>             Repository rep1 = new TransientRepository();
>             Session s1 = rep1.login(new SimpleCredentials("johndoe", "".toCharArray()));
>             Repository rep2 = new TransientRepository();
>             Session s2 = rep2.login(new SimpleCredentials("johndoe", "".toCharArray()));
> the root problem is the incorrect behavior of java.nio.channels.FileChannel#tryLock()
> which is demonstrated by the following code snippet:
>             try {
>                 FileLock fl1 = new FileOutputStream("foo").getChannel().tryLock();
>                 System.out.println("1st lock: " + fl1);
>                 FileLock fl2 = new FileOutputStream("foo").getChannel().tryLock();
>                 System.out.println("2nd lock: " + fl2);
>             } catch (Throwable t) {
>                 t.printStackTrace();
>             }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message