You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Sébastien Launay (JIRA)" <ji...@apache.org> on 2009/04/07 10:48:12 UTC
[jira] Created: (JCR-2057) When creating multiple repository
instances pointing to the same home, opening a second session will remove
the .lock file
When creating multiple repository instances pointing to the same home, opening 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: 1.5.3, core 1.4.7
Environment: Ubuntu Intrepid
Reporter: Sébastien Launay
The following test case can be used to reproduce the bug:
Repository repo1 = new TransientRepository(repoConfig);
Session session1_1 = repo1.login(...);
Session session2_2 = repo1.login(...);
Repository repo2 = new TransientRepository(repoConfig); // Will not fail (expected)
Session session2_1 = repo2.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
Session session2_2 = repo2.login(...); // Will work!
Repository repo3 = new TransientRepository(repoConfig); // Will not fail either (expected)
Session session3_1 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
Session session3_2 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: Directory was previously created with a different LockFactory 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 multiple 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 home must not be created
simultaneously but i think that it must be more robust to prevent data corruption.
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2057) When creating multiple repository
instances pointing to the same home, opening a second session will remove
the .lock file
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2057?page=com.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, opening 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ébastien 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 = new TransientRepository(repoConfig);
> Session session1_1 = repo1.login(...);
> Session session2_2 = repo1.login(...);
> Repository repo2 = new TransientRepository(repoConfig); // Will not fail (expected)
> Session session2_1 = repo2.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session2_2 = repo2.login(...); // Will work!
> Repository repo3 = new TransientRepository(repoConfig); // Will not fail either (expected)
> Session session3_1 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session3_2 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: Directory was previously created with a different LockFactory 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 multiple 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 home must not be created
> simultaneously but i think that it must be more robust to prevent data corruption.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2057) When creating multiple repository
instances pointing to the same home, opening a second session will remove
the .lock file
Posted by "Sébastien Launay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sébastien Launay updated JCR-2057:
----------------------------------
Attachment: JCR-2057-2009-04-07.zip
Test for reproducing this bug, dependencies are described in dependencies.txt.
> When creating multiple repository instances pointing to the same home, opening 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ébastien Launay
> Attachments: JCR-2057-2009-04-07.zip
>
>
> The following test case can be used to reproduce the bug:
> Repository repo1 = new TransientRepository(repoConfig);
> Session session1_1 = repo1.login(...);
> Session session2_2 = repo1.login(...);
> Repository repo2 = new TransientRepository(repoConfig); // Will not fail (expected)
> Session session2_1 = repo2.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session2_2 = repo2.login(...); // Will work!
> Repository repo3 = new TransientRepository(repoConfig); // Will not fail either (expected)
> Session session3_1 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session3_2 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: Directory was previously created with a different LockFactory 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 multiple 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 home must not be created
> simultaneously but i think that it must be more robust to prevent data corruption.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2057) When creating multiple repository
instances pointing to the same home, opening a second session will remove
the .lock file
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-2057.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.6.0
Fixed in revision: 763617
> When creating multiple repository instances pointing to the same home, opening 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ébastien Launay
> Fix For: 1.6.0
>
> Attachments: JCR-2057-2009-04-07.zip
>
>
> The following test case can be used to reproduce the bug:
> Repository repo1 = new TransientRepository(repoConfig);
> Session session1_1 = repo1.login(...);
> Session session2_2 = repo1.login(...);
> Repository repo2 = new TransientRepository(repoConfig); // Will not fail (expected)
> Session session2_1 = repo2.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session2_2 = repo2.login(...); // Will work!
> Repository repo3 = new TransientRepository(repoConfig); // Will not fail either (expected)
> Session session3_1 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session3_2 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: Directory was previously created with a different LockFactory 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 multiple 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 home must not be created
> simultaneously but i think that it must be more robust to prevent data corruption.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2057) When creating multiple repository
instances pointing to the same home, opening a second session will remove
the .lock file
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697443#action_12697443 ]
Marcel Reutegger commented on JCR-2057:
---------------------------------------
As indicated in the environment field, this only happens on a *nix box.
The RepositoryLock handling in the RepositoryImpl constructor is incorrect. The lock is acquired in a try/catch block with the rest of the initialization code. If anything goes wrong then the shutdown method is called, which also includes releasing the RepositoryLock. This also happens when the initialization fails due to an unsuccessful attempt to acquire the repository lock :-/
> When creating multiple repository instances pointing to the same home, opening 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ébastien Launay
> Attachments: JCR-2057-2009-04-07.zip
>
>
> The following test case can be used to reproduce the bug:
> Repository repo1 = new TransientRepository(repoConfig);
> Session session1_1 = repo1.login(...);
> Session session2_2 = repo1.login(...);
> Repository repo2 = new TransientRepository(repoConfig); // Will not fail (expected)
> Session session2_1 = repo2.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session2_2 = repo2.login(...); // Will work!
> Repository repo3 = new TransientRepository(repoConfig); // Will not fail either (expected)
> Session session3_1 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: The repository home /tmp/_repository appears to be already locked by the current process (expected)
> Session session3_2 = repo3.login(...); // Will fail with javax.jcr.RepositoryException: Directory was previously created with a different LockFactory 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 multiple 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 home must not be created
> simultaneously but i think that it must be more robust to prevent data corruption.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.