> From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
> Sent: Monday, August 05, 2013 7:56 AM
> To: Tomcat Users List
> Subject: Re: Auto-loading of the SQL Server JDBC Driver in 6.0.35
>
> On Aug 4, 2013, at 2:14 PM, mw...@loftware.com wrote:
>
> >> From: Mark Eggers [mailto:its_toas...@yahoo.com]
> >> Sent: Friday, August 02, 2013 5:28 PM
> >> To: Tomcat Users List
> >> Subject: Re: Auto-loading of the SQL Server JDBC Driver in 6.0.35
> >>
> >> On 8/2/2013 1:30 PM, mw...@loftware.com wrote:
> >>>> From: Michael-O [mailto:1983-01...@gmx.net] Sent: Friday, August
> >>>> 02,
> >>>> 2013 3:28 PM To: Tomcat Users List Subject: Re: Auto-loading of the
> >>>> SQL Server JDBC Driver in 6.0.35
> >>>>
> >>>> Am 2013-08-02 21:24, schrieb mw...@loftware.com:
> >>>>> I expect that by putting the SQL Server JDBC4 driver jar
> >>>>> (sqljdbc4.jar) into ${CATALINA_HOME}/lib, that the driver would be
> >>>>> automatically available upon server start. As expected, this
> >>>>> works in 6.0.33, but fails in 6.0.35. It seems that the fix to
> >>>>> Bug 51640 is the cause of this, and in fact, setting
> >>>>> driverManagerProtection to false in the
> >>>>> JreMemoryLeakPreventionListener allows this to work in 6.0.35 as
> >>>>> well. I would not have expected that a change to the MemoryLeak
> >>>>> Listener would have changed the behavior of the JDBC driver.
> >>>>>
> >>>>> I don't know the internals of the SQL Server driver, so I don't
> >>>>> know exactly why this is happening. The MySQL driver loads
> >>>>> without any issue.
> >>>>
> >>>> Why should the driver being loaded into memory if no one uses it?
> >>>> Actually, a driver is loaded into the container's classloader cache
> >>>> upon first access. This is what happens at least for me with the
> >>>> Oracle driver.
> >>>>
> >>>> Everything else does not make sense to me.
> >>>>
> >>>> Michael
> >>>
> >>> Sorry, I wasn't clear. It's not loading the driver into memory, but
> >>> rather registering it with the DriverManager that has changed, so
> >>> that it can be loaded on the first request. This is no longer occurring.
> >>>
> >>> Mark
> >>
> >> How are you accessing the driver?
> >>
> >> Are you using JDBC directly, or are you creating a JNDI pooled
> >> connection and letting Tomcat manage it.
> >>
> >> . . . . just my two questions
> >> /mde/
> >
> > Using the Apache JDBC pool with DataSources, but directly.
>
> Are you specifying a "driverClassName"? If you specify that and the JDBC
> driver is available on the class path then the pool should just work. No need
> to call DriverManager or load classes. The pool should handle that for you.
>
> See example for using the pool from Java.
>
> http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Plain_Ol'_Java
>
> Dan
>
No. And there is no need. Type 4 JDBC drivers are supposed to register
automatically. I have created a simple test; copying the Oracle, SQL*Server
and MySQL drivers into ${CATALINA_HOME}/lib; starting Tomcat and then running a
method that prints out the registered drivers (from
DriverManager.getDrivers()). With the default line below in server.xml, only
the JdbcOdbc bridge driver is registered.
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
/>
Driver Class
sun.jdbc.odbc.JdbcOdbcDriver
However, if I disable "driver manager protection" - effectively turn off the
fix for 51640, as shown below, the JdbcOdbc bridge AND the 3 other drivers are
all listed as registered. I will file a bug.
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
driverManagerProtection="false" />
Driver Class
sun.jdbc.odbc.JdbcOdbcDriver
com.mysql.jdbc.Driver
oracle.jdbc.OracleDriver
com.microsoft.sqlserver.jdbc.SQLServerDriver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
