Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <696811128.1240302947622.JavaMail.jira@brutus>
Date: Tue, 21 Apr 2009 01:35:47 -0700 (PDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-2057) When creating multiple repository
 instances pointing to the same home, opening a second session will remove
 the .lock file
In-Reply-To: <306780979.1239094092953.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/JCR-2057?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-2057:
-------------------------------

    Fix Version/s:     (was: 1.6.0)
                   1.5.5

Merged to the 1.5 branch in revision 767069.

> When creating multiple repository instances pointing to the same home, op=
ening a second session will remove the .lock file
> -------------------------------------------------------------------------=
-------------------------------------------------
>
>                 Key: JCR-2057
>                 URL: https://issues.apache.org/jira/browse/JCR-2057
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: core 1.4.7, 1.5.3
>         Environment: Ubuntu Intrepid
>            Reporter: S=C3=A9bastien Launay
>             Fix For: 1.5.5
>
>         Attachments: JCR-2057-2009-04-07.zip
>
>
> The following test case can be used to reproduce the bug:
> Repository repo1 =3D new TransientRepository(repoConfig);
> Session session1_1 =3D repo1.login(...);
> Session session2_2 =3D repo1.login(...);
> Repository repo2 =3D new TransientRepository(repoConfig); // Will not fai=
l (expected)
> Session session2_1 =3D repo2.login(...); // Will fail with javax.jcr.Repo=
sitoryException: The repository home /tmp/_repository appears to be already=
 locked by the current process (expected)
> Session session2_2 =3D repo2.login(...); // Will work!
> Repository repo3 =3D new TransientRepository(repoConfig); // Will not fai=
l either (expected)
> Session session3_1 =3D repo3.login(...); // Will fail with javax.jcr.Repo=
sitoryException: The repository home /tmp/_repository appears to be already=
 locked by the current process (expected)
> Session session3_2 =3D repo3.login(...); // Will fail with javax.jcr.Repo=
sitoryException: Directory was previously created with a different LockFact=
ory instance
> Open the first session in repo2 will fails but will also remove the .lock=
 file, thus the second
> session will succeed and may corrupt the repository because there are mul=
tiple session
> opened from multiple repository.
> The same behaviour occurs for repo3, the .lock file is removed but it is =
a slightly different case
> as a new exception will be thrown while creating the Lucene index.
> This is a clearly a twisted case as repositories pointing to the same hom=
e must not be created
> simultaneously but i think that it must be more robust to prevent data co=
rruption.
> I reproduce the bug on JR 1.4.7 and 1.5.3 but i think it affects at least=
 all versions of JR < 1.5.3.

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