From dev-return-22252-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Mar 04 12:18:24 2009 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 22163 invoked from network); 4 Mar 2009 12:18:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 12:18:23 -0000 Received: (qmail 60635 invoked by uid 500); 4 Mar 2009 12:18:22 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 60614 invoked by uid 500); 4 Mar 2009 12:18:22 -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 60598 invoked by uid 99); 4 Mar 2009 12:18:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 04:18:21 -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:18:19 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C6B0E234C4B6 for ; Wed, 4 Mar 2009 04:17:58 -0800 (PST) Message-ID: <1637595737.1236169078810.JavaMail.jira@brutus> Date: Wed, 4 Mar 2009 04:17:58 -0800 (PST) From: "Marcel Reutegger (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=12678711#action_12678711 ] Marcel Reutegger commented on JCR-2000: --------------------------------------- > Why do we need the thread killing in the first place? A normal join() call with no timeout should be fine enough Right, that would work well when one runs the test on a local machine. I had some build infrastructure in mind, where I want a report after the tests finished, which means termination must be guaranteed. > 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.