Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 38420 invoked from network); 4 Mar 2009 12:44:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 12:44:18 -0000 Received: (qmail 87637 invoked by uid 500); 4 Mar 2009 12:44:17 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 87604 invoked by uid 500); 4 Mar 2009 12:44:17 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 87588 invoked by uid 99); 4 Mar 2009 12:44:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 04:44:17 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 12:44:16 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 1FC48234C4AC for ; Wed, 4 Mar 2009 04:43:56 -0800 (PST) Message-ID: <2078426699.1236170636125.JavaMail.jira@brutus> Date: Wed, 4 Mar 2009 04:43:56 -0800 (PST) From: "Jukka Zitting (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-2000) Deadlock on concurrent commits In-Reply-To: <1999483538.1235576941753.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678716#action_12678716 ] Jukka Zitting commented on JCR-2000: ------------------------------------ Anyway, I don't feel too strongly about the join() issue. I suspect that the thread deaths I was seeing earlier were probably caused by an earlier deadlock blocking the threads that then were forcibly killed by the timeout mechanism, hiding the original cause of the problem. > 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, 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.