jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2000) Deadlock on concurrent commits
Date Wed, 04 Mar 2009 10:19:56 GMT

    [ https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678676#action_12678676
] 

Marcel Reutegger commented on JCR-2000:
---------------------------------------

> As far as I can tell, the lockups are caused by the test case forcibly terminating long-lived
threads.

I disagree. The tasks in ConcurrentVersioningWithTransactionsTest time out one year in the
future. Actually an unreasonable value ;), should be rather in the area of a couple of minutes,
to make sure the test terminates at some point if a deadlock occurs. RandomOperationTest indeed
uses a lower timeout of 60 seconds. If that's a problem, we should rather increase that value
to e.g. 5 minutes.

> However, the test code violates the "Don't mix concurrent transactional and non-transactional
writes to a single workspace" guideline

Hmm, I understand, but the above mentioned test works just fine in the 1.4 branch.

Przemo, does you application use XA transactions mixed with regular writes?

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


Mime
View raw message