[
https://issues.apache.org/jira/browse/JCR-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14526646#comment-14526646
]
Sam Stange commented on JCR-2598:
---------------------------------
Hi Unico,
Thank you for the response. I have a client that experienced a repository
corruption at the root node (cafebabe-cafe-babe-cafe-babecafebabe).
Essentially, it was not fixable (via console, other methodologies) without have
to go to a back-up. Our client wants us to prove validatehierarchy is going to
prevent this from happening again. I was hoping the unit test would validate
the setting, but it was unable to do so. Is there any way to verify this
setting will prevent a repository corruption?
> Saving concurrent sessions executing random operations causes a corrupt JCR
> ---------------------------------------------------------------------------
>
> Key: JCR-2598
> URL: https://issues.apache.org/jira/browse/JCR-2598
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.6.1, 2.0
> Reporter: Stephan Huttenhuis
> Assignee: Jukka Zitting
> Fix For: 1.6.4, 2.0.3, 2.1.1, 2.2
>
> Attachments: ConcurrencyTest3.java, JCR-2598-II.patch,
> JCR-2598.patch, Output after patch.txt, Output before patch.txt,
> org.apache.jackrabbit.core.ConcurrencyTest3.txt
>
>
> Run the attached unit test. Several concurrent sessions add, move, and remove
> nodes. Then the index is removed and the repository is again started. The
> repository is in an inconsistent state and the index cannot be rebuild. Also
> a lot of exceptions occur. See (see Output before patch.txt). Note that the
> unit test also suffers from the deadlock of issue
> http://issues.apache.org/jira/browse/JCR-2525 about half the time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)