Bug 55662 - Add a way to set an instance of java.sql.Driver directly on org.apache.tomcat.jdbc.pool.DataSource
Summary: Add a way to set an instance of java.sql.Driver directly on org.apache.tomcat...
Status: NEW
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: Macintosh All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2013-10-17 13:29 UTC by Ben Hale
Modified: 2019-07-07 15:57 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Ben Hale 2013-10-17 13:29:20 UTC
Currently when org.apache.tomcat.jdbc.pool.DataSource is directly instantiated (e.g. in an IoC environment), the only way to set the type of java.sql.Driver that is should use is by passing in a String classname which is then passed to DriverManager.  The downside to this is that it requires the DataSource and the Driver to be in the same classloader.  In practice many times the Driver is in the application classloader while the DataSource is in the container classloader meaning that other than packaging a Tomcat JAR in your application you cannot use the DataSource directly.

It'd be great to have a way to pass the actual instance of Driver to the DataSource and have it use that instead of going to DriverManager to find it.  This would enable standard classloader inheritance to work properly and allow the non-adjacent packaging of the Driver and DataSource.

An example of this style of configuration can be found in Spring's SimpleDriverDataSource[1].

[1]: http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/jdbc/datasource/SimpleDriverDataSource.html#setDriver(java.sql.Driver)
Comment 1 Mark Thomas 2016-03-14 16:01:51 UTC
Correct module
Comment 2 Jonathan Leech 2017-07-11 15:19:44 UTC
The DataSource or the ConnectionPool should also own the Driver instance, rather than the PooledConnection object. That a new instance of the Driver is instantiated via reflection for every Connection the pool creates is benign in most cases and catastrophic in others (e.g. Apache Phoenix will create a set of zookeeper connections for each instance of PhoenixDriver, which blows up spectacularly). Standard JDBC has the DriverManager create the single instance of the driver. Tomcat-dbcp seems to get it mostly right, although I think Java's DriverManager may create an instance of the Driver, and each pool may create a redundant one.