Bug 55662

Summary: Add a way to set an instance of java.sql.Driver directly on org.apache.tomcat.jdbc.pool.DataSource
Product: Tomcat Modules Reporter: Ben Hale <nebhale>
Component: jdbc-poolAssignee: Tomcat Developers Mailing List <dev>
Status: NEW ---    
Severity: enhancement    
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Hardware: Macintosh   
OS: All   

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.