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 > We have to , as this is an avenue for our users to access their databases > from within our product, and we really don't have any idea which JDBC drivers > our customers will be using, and we don't want them changing our > configuration files. It DOES seem if you go the JNDI-DataSource route that > the driver is forcibly loaded. Also worthwhile to note that > DriverManager.getConnection fails as well (which I guess isn't surprising). > > Mark > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
