Bug 968361 - Improve database plugin design to support connection pooling

Thomas Segismont tsegismo at redhat.com
Fri Jan 10 14:02:53 UTC 2014


Hi Elias,

Le 05/01/2014 00:19, Elias Ross a écrit :
> Yes I didn't work to maintain backwards compatibility. One discussed
> issue was including the additional library dependencies. One original
> request was to rely on the database pooling provided by each vendor's
> driver version, but I found that to be too tedious to implement.
>
> One benefit in using the BoneCP library is that especially in
> transitioning to using pooled connections, I was leaking connections
> in code. Prepared statements as well. The benefit of the library is
> that it will identify such bugs, prevent bad plugin code from using
> too many connections, as well as automatically clean up connections no
> longer used--i.e. fix bugs that do occur.
>

Yes I was at the beginning in favor of using pooled connection tools 
provided by each database driver. What changed my mind is:

* the ability to write less code in concrete database plugins (they only 
have to load the JDBC driver class)
* the all in all limited impact the additional libraries have (plugin 
code does not use the Guava classes, only BoneCP code does, so it's 
probably a matter of a few classes)

> One thing which I didn't get to work is being able to (possibly) load
> the JDBC driver from disk and not require a separate plugin for each
> vendor's database. Is this something that can be done?

Currently... no. Resource class loaders may load additional libraries 
thanks to the ClassLoaderFacet class (which their discovery class must 
implement). But that's just for /resource/ component classloaders.

I recommend to read the wiki page on plugin extensions and in particular 
the "Discovery Classloaders" section.
https://docs.jboss.org/author/display/RHQ/AMPS-Plugin+Extensions#AMPS-PluginExtensions-DiscoveryClassloaders

Cheers,
Thomas


More information about the rhq-devel mailing list