Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 8506 invoked from network); 9 Jul 2009 07:04:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Jul 2009 07:04:29 -0000 Received: (qmail 87524 invoked by uid 500); 9 Jul 2009 07:04:39 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 87449 invoked by uid 500); 9 Jul 2009 07:04:39 -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 87441 invoked by uid 99); 9 Jul 2009 07:04:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 07:04:39 +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.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 07:04:36 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C78B1234C004 for ; Thu, 9 Jul 2009 00:04:14 -0700 (PDT) Message-ID: <578368763.1247123054801.JavaMail.jira@brutus> Date: Thu, 9 Jul 2009 00:04:14 -0700 (PDT) From: "Stefan Guggisberg (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-2197) Support configuration of timeout in Statements for Database implementations In-Reply-To: <1363750034.1247091194811.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729077#action_12729077 ] Stefan Guggisberg commented on JCR-2197: ---------------------------------------- is the suggested new feature meant as a work-around for an oracle jdbc driver issue? > Support configuration of timeout in Statements for Database implementations > --------------------------------------------------------------------------- > > Key: JCR-2197 > URL: https://issues.apache.org/jira/browse/JCR-2197 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-core > Affects Versions: 1.5.6 > Reporter: Micah Whitacre > Priority: Minor > > Allowing for the configuration and usage of a timeout value for Statements[1] would provide a means avoiding dead lock when a long running/stalled SQL Statement holds onto a lock preventing other threads from acquiring locks. > The situation i have seen is where a JVM handling multiple request each in its own Thread will at some points become stalled. At the start of each thread processing the request it will acquire its own session to the repository which stores all information in an an Oracle database. The issue we are seeing is that deadlock occurs because the SQL write statement to the VersionManager is taking too long/stalling in the Oracle driver code. Since it is writing, the write lock is acquired and this prevents other threads from acquiring a session because they get blocked trying to acquire the read lock of the Version Manager. > If the SQL statement timed out after a certain time, this would alleviate the problem of threads continually hanging and make use of the Jackrabbit auto reconnect functionality. The user of timeout is supported when using JNDI so this request would move it towards being first class support on the database implementations. > [1] - http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Statement.html#setQueryTimeout(int) > [2] - http://forums.sun.com/thread.jspa?threadID=343023&start=30&tstart=0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.