jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-785) Updates to multiple workspaces (e.g. in a transaction) locked in cluster journal
Date Mon, 12 Mar 2007 09:23:09 GMT

     [ https://issues.apache.org/jira/browse/JCR-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dominique Pfister resolved JCR-785.

    Resolution: Fixed

Made the read-write lock in o.a.j.core.journal.AbstractJournal re-entrant, allowing the same,
commiting thread to reacquire the write-lock. All transaction-related tests in XATest now
pass successfully.

Fixed in revision 517141.

> Updates to multiple workspaces (e.g. in a transaction) locked in cluster journal
> --------------------------------------------------------------------------------
>                 Key: JCR-785
>                 URL: https://issues.apache.org/jira/browse/JCR-785
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.2.3
>            Reporter: Dominique Pfister
>         Assigned To: Dominique Pfister
> Running a transaction that updates multiple workspaces (e.g. a versioning operation)
will be locked, as they all try to acquire a non-reentrant lock in the cluster's journal.
Short-term fix is to make the lock re-entrant. In the long run, a transaction context sensitive
lock may be more appropriate.
> How to reproduce: enable clustering in the test environment and let the test o.a.j.core.XATest.testSetVersionLabel()
run. This will result in a deadlock when committing the operation.
> This was initially reported by Rafał Kwiecień as a problem when using springmodules
and clustering but turned out to be general problem with transactions and clustering. Thanks
for reporting it!

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message