jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-2000) Deadlock on concurrent commits
Date Mon, 02 Mar 2009 10:58:12 GMT

     [ 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.


Mime
View raw message