[
https://issues.apache.org/jira/browse/JCR-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800149#action_12800149
]
Thomas Mueller commented on JCR-2456:
-------------------------------------
According to my test, it didn't have a measurable effect.
I have committed a simple benchmark in revision 899102.
(my idea is to extend it in the future, and then to run it as part of the
integration test;
but I didn't add it yet because running the test without checking the result
doesn't make sense).
The result is:
run: 4; time: 1270 ms; task: addNodes (without patch)
run: 4; time: 1245 ms; task: addNodes (with patch)
(the difference is within the margin of error; sometimes it's faster sometimes
slower)
I guess the only part that could measurable affect performance is
SharedItemStateManager.checkAddedChildNode, specially persistMgr.exists.
It was never called for my test case (when running in debug mode), because
the added node always was in the cache.
> Repository is corrupt after concurrent changes with the same session
> --------------------------------------------------------------------
>
> Key: JCR-2456
> URL: https://issues.apache.org/jira/browse/JCR-2456
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0-beta4
> Reporter: Thomas Mueller
> Attachments: patch-2456.txt, TestMultiThread.java
>
>
> After concurrent write operations using the same session, the repository can
> get corrupt, meaning a ItemNotFoundException is thrown when trying to remove
> a node.
> Concurrent write operations are not supported, however I believe the
> persistent state of the repository should not be get corrupt.
> One way to solve this problem is to synchronize on the session internally.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
