[jira] Created: (JCR-1456) Database connection pooling

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

Matej Knopp commented on JCR-1456:
----------------------------------

I'm not sure what to do about the missing methods from DataSource. We can add dummy implementation to make it compile but that doesn't really solve the problem (if the real datasource implements methods from Wrapper interface).

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

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

Martijn Hendriks commented on JCR-1456:
---------------------------------------

In order to make testing on other databases than Derby easier, I've created a new profile in jackrabbit-core and new configuration files in src/test/repository-filtered.
The profile copies the test configuration files from src/test/repository-filtered and filters them against properties specified in the pom. The core tests can then be run, e.g., against a configuration which puts all data in a MySQL database.

I think that this makes testing the core against other than the Derby backend easier. Shall I commit this to the sandbox branch which has been created for this issue?

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

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

Stefan Guggisberg commented on JCR-1456:
----------------------------------------

> Shall I commit this to the sandbox branch which has been created for this issue?

+1

great, thanks!

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

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

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

Martijn Hendriks commented on JCR-1456:
---------------------------------------

I've taken the liberty to take the next step: see revision 801659. I've replaced the DataSource field with a ConnectionHelper field, removed the Context from the method signatures and basically put the Context's state in the ConnectionHelper. I've also moved checkSchema and prepareSchemaObjectPrefix to the ConnectionHelper class. Database specific code is now contained in the ConnectionHelper class hierarchy and this hierarchy can be reused in other database dependent packages. The BundleDbPM's init method now calls a "createConnectionHelper" method which subclasses can override to use a specialized ConnectionHelper.

At least the following builds succeed:
* mvn clean integration-test  (Derby and local FS backend)
* mvn clean test -Puse-descriptor-overlay,mysql  (MySQL backend, ignoring GCTest failure)
* mvn clean test -Puse-descriptor-overlay,mssql  (MSSQL backend, ignoring GCTest failure)

Known open issues:
* The H2, Oracle and Postgres PMs are broken (I've made it compile by commenting code out)
* Make the pooling smarter (ConnectionFactory)
* Add pooling to other DB based packages: db fs, db journal, db datastore, regular db pms.
* blockOnConnectionLoss feature and retrying on failure strategy must be checked.

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

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

Martijn Hendriks commented on JCR-1456:
---------------------------------------

I think that it is a good point to ask some feedback about the direction that the work on the sandbox branch is taking.

What has been done:
* A getDataSource method has been added to the ConnectionFactory which creates and returns a pooled datasource (commons-dbcp).
* Maven profiles and some infrastructure have been added which make running the automated tests against different DB backends easier.
* A DB uitility packages has been added: o.a.j.c.util.db. Classes from o.a.j.c.persistence.bundle.util have been moved there, and most importantly, it contains the ConnectionHelper class hierarchy. This hierarchy uses a DataSource provided by the Connectionfactory and provides a means to execute SQL and has specializations for several DB types. Most notably, the Oracle10R1ConnectionHelper implements special blob handling. It also contains a CheckSchemaOperation class which encapsulates the logic to check and create DB schemas (using a ConnectionHelper).
* The bundle PMs and the DB Filesystem classes have been refactored to use the ConnectionHelper and CheckSchemaOperation classes. The PM and FS classes serve as factories for ConnectionHelper and CheckSchemaOperation instances.

What must still be done:
* Refactor remaining db based packages to use the ConnectionHelper and CheckSchemaOperation. (journal, datastore, and maybe the non-bundle pms).
* Improve the implementation of Connectionfactory.getDataSource (now it creates a new DataSource for each invocation with default properties....)
* ....
* A lot of integration testing

So what do you think about the current direction?

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

     [ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martijn Hendriks updated JCR-1456:
----------------------------------

    Fix Version/s: 2.0.0

I think this should be fixed in 2.0.0.

> 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
>             Fix For: 2.0.0
>
>         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.

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

Jukka Zitting commented on JCR-1456:
------------------------------------

I gave a quick look at the current state in the sandbox branch, and I'm pretty happy with how this has turned out!

Agreed about targeting this for Jackrabbit 2.0. We should start looking at merging the changes back to trunk so they'll go out in the 2.0 betas for more testing before the final 2.0 release.

> 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
>             Fix For: 2.0.0
>
>         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.

     [ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-1456:
-------------------------------

    Attachment: JCR-1456.patch

Attached a patch showing the full set of changes between the JCR-1456 sandbox branch and the latest trunk.

Anyone opposed to merging these changes to trunk? There's obviously still some work to be done, but I think the current state is already good enough to be included in the 2.0 beta releases.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

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

Thomas Mueller commented on JCR-1456:
-------------------------------------

Is the 20% slowdown problem solved? I think that should be solved before merging to trunk (disabling validation or doing validation on idle).

P.S. JCR-1456.patch looks like a 'reverse patch'.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

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

Stefan Guggisberg commented on JCR-1456:
----------------------------------------

> Is the 20% slowdown problem solved? I think that should be solved before merging to trunk (disabling validation or doing validation on idle).

i agree with thomas. i'd be okay to merging these changes to trunk if the performance issue has been resolved.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

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

Martijn Hendriks commented on JCR-1456:
---------------------------------------

I think that the "testWhileIdle" approach for the DataSources managed by Jackrabbit resolves the performance issue (this is already present in the sandbox branch). I will try to get some more test results tomorrow. What I intend to do is measure the time that it takes to build the jackrabbit-core up to the integration-test phase on MySQL, MSSQL, H2 and Oracle backends. I compare the sandbox branch with a close revision in the trunk. I hope that these build-times are approximately the same. Is that enough, or should we do some more measurements?

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

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

Stefan Guggisberg commented on JCR-1456:
----------------------------------------

> [...] Is that enough, or should we do some more measurements?

that would be fine with me, thanks.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

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

Thomas Mueller commented on JCR-1456:
-------------------------------------

> Is that enough

That's enough, thanks.

Could you post the test code / setup or describe what you tested? So that we can reproduce the results if needed. Just to protect from those who say "The new version *feels* slower..."

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

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

Martijn Hendriks commented on JCR-1456:
---------------------------------------

Sure, I'll describe what I did as precisely as possible. All thanks for your feedback.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456.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.

     [ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martijn Hendriks updated JCR-1456:
----------------------------------

    Attachment: JCR-1456-performance-trunk-test-setup.patch
                JCR-1456-performance.txt

I attached the results of the performance test and also a patch against the trunk which I applied to setup the tests. There seems to be some overhead as a result of the patch. One case, however, shows quite dramatic performance loss (50%). I want to find out what causes this.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456-performance-trunk-test-setup.patch, JCR-1456-performance.txt, JCR-1456.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.

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

Stefan Guggisberg commented on JCR-1456:
----------------------------------------

thanks for sharing the results. they do look very promising.
i am pretty sure thomas has an idea how to explain/address
to +50% on h2.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456-performance-trunk-test-setup.patch, JCR-1456-performance.txt, JCR-1456.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.

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

Thomas Mueller commented on JCR-1456:
-------------------------------------

Strange is that Connection.getAutoCommit() is called so much (maybe 50% of all JDBC method calls). Sometimes it is called 4 times in a row, without any other JDBC calls in between. It's not a problem for most databases (specially embedded), but I wonder why it is called so much and if this could be avoided.

I just tested H2 embedded. I don't know why H2 got slower in your case, maybe because you set the trace level to the maximum, or because you have used the server mode (I used embedded and disabled the trace output).

127 seconds with trunk
131 seconds with JCR-1456
Maven 2.0.9, 1.5.0_20, Mac OS 10.5.8

Unrelated to JCR-1456: I had to disable the H2 shutdown hook because one of tests doesn't seem to close the repository correctly, so that Jackrabbit executes database statements in a shutdown hook. This only happens in the trunk, not in JCR-1456.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456-performance-trunk-test-setup.patch, JCR-1456-performance.txt, JCR-1456.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.

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

Jukka Zitting commented on JCR-1456:
------------------------------------

The AutoCommit stuff shouldn't be needed with connection pooling anymore, the AutoCommit mode should simply always be off.

We use the AutoCommit mode to avoid having to add explicit commit() calls even after read-only operations. It's being switched on an off depending whether the repository is performing a read or a write operation. Now with the connection pool a connection is simply closed (or reclaimed to the pool) after a read operation ends, so no pending transaction state starts to accumulate on the database side.

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456-performance-trunk-test-setup.patch, JCR-1456-performance.txt, JCR-1456.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.

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

Martijn Hendriks commented on JCR-1456:
---------------------------------------

(Sorry for the late reply...)

> Strange is that Connection.getAutoCommit() is called so much (maybe 50% of all JDBC method calls). Sometimes it is called 4 times in a row

The commons-dbcp pool calls getAutoCommit on each borrow and on each return and ConnectionHelper.getConnection also calls it. That's three. I agree that the number of calls to getAutoCommit is very large: 28756 vs 759 on the trunk for the tests.

> I just tested H2 embedded. I don't know why H2 got slower in your case

I see the same: H2 embedded is just a couple of seconds slower. Using H2 in server mode over TCP (localhost), however, (using tracing or not) is significantly slower. This might have something to do with the large number of getAutoCommit calls....?

> The AutoCommit stuff shouldn't be needed with connection pooling anymore, the AutoCommit mode should simply always be off.

I don't think that changing the default for autoCommit changes the number of calls to getAutoCommit. Can we just keep this default or is there another reason to make the default "false"?

> 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
>             Fix For: 2.0.0
>
>         Attachments: 777490.patch, dbcp.patch, dbcp.patch, JCR-1456-performance-trunk-test-setup.patch, JCR-1456-performance.txt, JCR-1456.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.