On 2/13/2015 11:54 AM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
...
public static void unRegisterDrivers() { try { for (
Enumeration<Driver> drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log
the exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this
probably isn't really changing anything.
We manage the pooling in our application, and don't use any of
TC's connection pooling. This is largely because several years ago
(long enough ago that the then-current version of TC was 5.5.25)
the app was moved from another servlet container that either didn't
have pooling, or it was harder to use than it was to write out own.
I wasn't in on the initial development, but did the port to TC.
And at the time I did the port, I had no idea about TC's connection
pooling, so continued with our own pooling implementation.
Until I did this, I could not get rid of the memory leak warnings.
If there is another way, I couldn't find it at the time I was
messing with it...
I'm not sure at what point Tomcat started de-registering drivers. When
it de-registers a driver, it gives you a warning. By you doing it
yourself, you are avoiding the warning, of course.
But if you de-register all drivers, you are also de-registering any
drivers that were registered by different web applications, Tomcat's
connection-pool, etc. It would be better to only de-register the
driver(s) you actually registered in the first place.
I haven't researched such things, but a reasonable way might be to do
something like this:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
for(Driver driver : DriverManager.getDrivers())
if(cl.equals(driver.getClass().getClassLoader()))
DriverManager.deregisterDriver(driver);
This way, you only remove drivers you load yourself. Alternatively,
you probably already know which drivers you have explicitly loaded, so
you could explicitly unload them instead of flushing the whole
DriverManager.
Note: I have no idea if Driver objects get the proper ClassLoader
assigned, but it's worth a try to get a bit more safety.
If your web application is the only one loaded, feel free to wipe-out
the DriverManager like that. But, if you need to operate in a shared
environment, your technique above might negatively impact other code
that relies on its driver not being forcibly un-loaded out from under it.
Thanks for the suggestions, Chris! The way we operate our environment
currently there's no danger of killing another app, but I'll look into
your suggestion for future reference. I'm always open to suggestions on
ways to improve my coding.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
