[
https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-2000:
-------------------------------
Attachment: search-on-sism.patch
The culprit seems to be the system search manager, that (like LockManager
above) uses the SessionItemStateManager of the system session for looking up
items. The attached patch (search-on-sism.patch) makes the system search
manager use the underlying SharedItemStateManager instance instead of the
SessionItemStateManager.
> 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, search-on-sism.patch,
> thread-join.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.
