[
https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678339#action_12678339
]
Jukka Zitting commented on JCR-2000:
------------------------------------
There are other lockups too. However, the test code violates the "Don't mix
concurrent transactional and non-transactional writes to a single workspace"
guideline mentioned in http://jackrabbit.apache.org/concurrency-control.html.
I've disabled the Thread.stop() calls and the mixed normal and transactional
saves, which seems to avoid all the problems. I'll run a bigger randomized test
over the night to see whether any problems remain.
> Deadlock on concurrent commits
> ------------------------------
>
> Key: JCR-2000
> URL: https://issues.apache.org/jira/browse/JCR-2000
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.5.3
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.5.4
>
> Attachments: JCR-2000.patch, JCR-2000.patch
>
>
> As reported in the followup to JCR-1979, there's a case where two
> transactions may be concurrently inside a commit. This is bad as it breaks
> the main assumption in http://jackrabbit.apache.org/concurrency-control.html
> about all transactions first acquiring the versioning write lock.
> Looking deeper into this I find that the versioning write lock is only
> acquired if the transaction being committed contains versioning operations.
> This is incorrect as all transactions in any case need to access the version
> store when checking for references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
