+++ This bug was initially created as a clone of Bug #968361 +++

Description of problem:
The current database plugin design is based on the assumption that a single connection object will me maintained by the top level database resource.

This works as long as no long running transaction is started (connection remains in autocommit mode). Otherwise statements could no longer be run concurrently on the same connection.

Another problem is that the shared connection can be closed if a plugin class calls org.rhq.plugins.database.DatabaseComponent#removeConnection while it is still used elsewhere by another thread.

The database plugin design should be improved to support connection pooling from the top level database resource.

Version-Release number of selected component (if applicable):
4.7

--- Additional comment from Elias Ross on 2013-08-01 19:48:58 CEST ---

Uses BoneCP, which is fairly small but requires 'guava' library which is a little large. I don't have a strong opinion about using more memory for RHQ agent.

I've done only minimal testing against PostgreSQL. I've tested more using Oracle and MySQL.

One thing NOT working is loading the database library .jar by path. I don't really understand how the Classpath Extension works (or doesn't.) So maybe this needs to come out.

--- Additional comment from Heiko W. Rupp on 2013-08-15 11:55:35 CEST ---

Thomas, can you work with Elias, who provided a patch?

--- Additional comment from Thomas Segismont on 2014-01-02 14:28:52 CET ---

Fixed in master

commit 2b810f1c9fa247a9d8ddf08d2b9ba93c9e1cf2a6
Author: Thomas Segismont <tsegismo>
Date:   Tue Dec 17 21:35:47 2013 +0100

This changeset introduces a new API for database plugins and deprecates the previous one. Compatibility with the previous API will be maintained until next major version of RHQ.

The 'rhq-database-plugin' was based on org.rhq.plugins.database.DatabaseComponent interface which encouraged plugin authors to share a single JDBC connection across database components. This was wrong for various reasons (connection leaks, concurrent JDBC calls... etc).

The new API introduces three important classes:
* org.rhq.plugins.database.PooledConnectionProvider
* org.rhq.plugins.database.BasePooledConnectionProvider
* org.rhq.plugins.database.ConnectionPoolingSupport

BasePooledConnectionProvider is a base implementation of a PooledConnectionProvider. Plugin authors should create a concrete implementation of BasePooledConnectionProvider which overrides the #getDriverClass() method. This is important if a database plugin embeds a JDBC driver: the database-specific driver class must be loaded by the child plugin classloader.

ConnectionPoolingSupport helps to manage the compatibility with the old API. It's a contract that all new database resource components should obey to. It declares the following methods:
* #supportsConnectionPooling()
* #getPooledConnectionProvider()
Results of calls to #supportsConnectionPooling() #getPooledConnectionProvider() must be consistent. In practice, a top level server database component should be able to create a PooledConnectionProvider instance, and child servers and services should indicate they support connection pooling only if their parent component does.

The 'rhq-database-plugin' embeds the BoneCP library (JDBC connection pooling) and its dependencies (Google's Guava). Child plugins will have all the classes accessible as soon as they have this node in their plugin descriptor:
===
<depends plugin="Database" useClasses="true"/>
===

This changeset includes the necessary changes to support connection pooling in the Oracle, Postgres and MySQL plugins.

--- Additional comment from Heiko W. Rupp on 2014-04-23 14:31:14 CEST ---

Bulk closing of 4.10 issues.

If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10.

--- Additional comment from Thomas Segismont on 2014-05-09 16:58:12 CEST ---

Additional commit in master (back in December)

commit 1eb8c728c0c1939115fe90bd1c91fbf5ecf0a036
Author: Thomas Segismont <tsegismo>
Date:   Tue Dec 17 21:35:47 2013 +0100