tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Mikusa <dmik...@gopivotal.com>
Subject Re: Auto-loading of the SQL Server JDBC Driver in 6.0.35
Date Mon, 05 Aug 2013 11:55:36 GMT
On Aug 4, 2013, at 2:14 PM, MWick@loftware.com wrote:

>> From: Mark Eggers [mailto:its_toasted@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, MWick@loftware.com wrote:
>>>> From: Michael-O [mailto:1983-01-06@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 MWick@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message