From dev-return-24737-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Sun Aug 02 18:19:32 2009 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 15963 invoked from network); 2 Aug 2009 18:19:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Aug 2009 18:19:32 -0000 Received: (qmail 59759 invoked by uid 500); 2 Aug 2009 18:19:37 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 59681 invoked by uid 500); 2 Aug 2009 18:19:37 -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 59672 invoked by uid 99); 2 Aug 2009 18:19:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Aug 2009 18:19:37 +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; Sun, 02 Aug 2009 18:19:35 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id EDFDF234C004 for ; Sun, 2 Aug 2009 11:19:14 -0700 (PDT) Message-ID: <1667074811.1249237154967.JavaMail.jira@brutus> Date: Sun, 2 Aug 2009 11:19:14 -0700 (PDT) From: "Martijn Hendriks (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-1456) Database connection pooling In-Reply-To: <1013679260.1204733501006.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-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738108#action_12738108 ] Martijn Hendriks commented on JCR-1456: --------------------------------------- Committed in revision 800118. Using a different DB backend for testing can be done as follows: * Edit the relevant properties in the pom of the jackrabbit-core's use-descriptor-overlay profile. * Make sure you have the appropriate DB driver on the classpath (a MySQL driver is already there) * Run mvn clean integration-test -Puse-descriptor-overlay Note that the profile drops and recreates the test database in the clean phase. I recently have been looking at refactoring the database classes a bit to remove duplication in e.g., all these bean properties (username, password, schema object prefix, etc) and, more importantly, methods like checkSchema. The idea was to have a base class, say DbSupport, with all these common properties and methods and and with a method to get a sort of JDBC helper class which encapsulates the Connection and operations on it (something like the ConnectionRecoveryManager). I had various subclasses of the JDBC helper in mind for the various DB types (Oracle9, Derby). This works quite nicely for the core.fs.db package and connection pooling can then be located inside that JDBC helper class. I was wondering if that could help us here. What if the Operations that are mentioned above use such as JDBC helper class? > Database connection pooling > --------------------------- > > Key: JCR-1456 > URL: https://issues.apache.org/jira/browse/JCR-1456 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core > Reporter: Jukka Zitting > Attachments: 777490.patch, dbcp.patch, dbcp.patch, patch-1456-1.txt, patch-1456-2.txt, patch-1456-3.txt > > > Jackrabbit should use database connection pools instead of a single connection per persistence manager, cluster journal, or database data store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.