From dev-return-28988-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Aug 06 07:44:49 2010 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 34138 invoked from network); 6 Aug 2010 07:44:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Aug 2010 07:44:48 -0000 Received: (qmail 39177 invoked by uid 500); 6 Aug 2010 07:44:48 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 38837 invoked by uid 500); 6 Aug 2010 07:44:45 -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 38828 invoked by uid 99); 6 Aug 2010 07:44:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Aug 2010 07:44:44 +0000 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.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Aug 2010 07:44:42 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o767iKrt002746 for ; Fri, 6 Aug 2010 07:44:20 GMT Message-ID: <3543719.196291281080660715.JavaMail.jira@thor> Date: Fri, 6 Aug 2010 03:44:20 -0400 (EDT) From: =?utf-8?Q?Hugo_Lassi=C3=A8ge_=28JIRA=29?= To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-2679) Lock Problem when accessing JCR In-Reply-To: <7120517.419671279289151673.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-2679?page=3Dcom.atlassian.j= ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D128959= 83#action_12895983 ]=20 Hugo Lassi=C3=A8ge commented on JCR-2679: ------------------------------------ I agree that the datasource was too small. However I think there is a lot o= f different concurrent problems : - the size of the database pool - the deadlock in jackrabbit (the same as in JCR-2345) in AbstractBundlePer= sistenceManager - the number of starting transactions waiting to acquire the write lock in = DefaultISMLocking Even if our database pool is exhausted temporarily, is the correct behaviou= r if Jackrabbit ran into a deadlock ? > Lock Problem when accessing JCR > ------------------------------- > > Key: JCR-2679 > URL: https://issues.apache.org/jira/browse/JCR-2679 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jca, transactions > Affects Versions: 1.5.3, 1.6.2 > Environment: JBOSS 4.2.3 on jre 1.5.0_15 with XA transactions and= Oracle10g > Reporter: Laurent Prevosto > Priority: Critical > Attachments: repository-prod.xml, thread_dump.txt, workspace.xml > > > Hi, > We're using Jackrabbit 1.6.2 as an internal CMS in an application we deve= lopped. > It runs in JBOSS 4.2.3 on jre 1.5.0_15 with XA transactions and Oracle10g > We have about 15 users adding / deleting files in the repository. > 30 others just do read only CMS access and other stuff. > Things work fine except that sometimes, suddenly everything gets stuck an= d all we have left is those kind of errors : > [org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl] : Exception re= trieving Node with UUID : XXXXXXX-XXX-etc: javax.jcr.ItemNotFoundException:= XXXXXXX-XXX-etc > All our JCR connections are now dead. If we restart JBOSS, things get bac= k to normal, until the next crash. > It looks like the bug usually happens when this kind of sequence takes pl= ace (though that may not be the only one) : > XA transaction begins > filenode1 gets deleted > filenode2 gets deleted > other oracle stuff takes place... and fails > XA rollbacks. > =3D> JCR is dead. > At that point, "touching" the datasource has it reinitialised by JBOSS bu= t unfortunately the lock is still there : JBOSS has to be restarted. --=20 This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.