[
https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-2000:
-------------------------------
Attachment: JCR-2000.patch
Attached a patch that solves the issue for environments where the transaction
manager does not use separate threads for preparing and committing a
transaction (see JCR-1334). Support for JCR-1334 requires updating also the
version manager lock to support switching the lock ownership from one thread to
another.
> 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
>
>
> 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.
