Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 9809 invoked from network); 25 May 2006 10:10:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 May 2006 10:10:23 -0000 Received: (qmail 56250 invoked by uid 500); 25 May 2006 10:10:18 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 56030 invoked by uid 500); 25 May 2006 10:10:16 -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 55553 invoked by uid 99); 25 May 2006 10:10:14 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 03:10:14 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 03:10:13 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 5A58471429B for ; Thu, 25 May 2006 10:09:32 +0000 (GMT) Message-ID: <10448435.1148551772365.JavaMail.jira@brutus> Date: Thu, 25 May 2006 10:09:32 +0000 (GMT+00:00) From: "Tobias Bocanegra (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Closed: (JCR-443) Deadlock when concurrently committing and reading versioning states In-Reply-To: <21610932.1148551289780.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 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/JCR-443?page=all ] Tobias Bocanegra closed JCR-443: -------------------------------- Resolution: Fixed fixed. Date: Thu May 25 03:04:54 2006 New Revision: 409351 > Deadlock when concurrently committing and reading versioning states > ------------------------------------------------------------------- > > Key: JCR-443 > URL: http://issues.apache.org/jira/browse/JCR-443 > Project: Jackrabbit > Type: Bug > Versions: 1.0, 0.9 > Environment: r4093490 > Reporter: Tobias Bocanegra > > there is a rear occation when one thread commits a transaction and another thread reads versioing related information, so that a deadlock can occurr. > example: > Thread1: > ut.begin(); > session.getWorkspace().clone("default", "/content", "/content", true); > ut.commit(); > Thread2: > VersionHistory vh = folder.getVersionHistory(); > VersionIterator iter = vh.getAllVersions(); > while (iter.hasNext()) { > Version v = iter.nextVersion(); > } > to fix this issue we must ensure, that methods below the shareditemstatemgr do not call higher instances (like itemmgr) again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira