Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <183296493.1247145855095.JavaMail.jira@brutus>
Date: Thu, 9 Jul 2009 06:24:15 -0700 (PDT)
From: "Thomas Mueller (JIRA)" <jira@apache.org>
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


    [ https://issues.apache.org/jira/browse/JCR-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729258#action_12729258 ] 

Thomas Mueller commented on JCR-2197:
-------------------------------------

> Does a data store play nicely in a clustered environment?

Yes.

> generally about 10-50k

Binaries of this size may or may not benefit from using a data store. I would try.

> 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.