My personal advice with the Oracle driver is to put it at the server level, not at the webapp level. For instance if you use the query timeouts, oracle JDBC spawns a Thread to handle the timeouts, and there is no way to properly stop this thread so tomcat will continue complaining about leaking a classloader... With the driver at the server level, the warnings will disappear and your webapp won't leak (or at least not because of the JDBC driver).
Sylvain On 20 juil. 2011, at 22:59, Mark Thomas wrote: > On 20/07/2011 21:46, Christopher Schultz wrote: >> Mark, >> >> On 7/20/2011 4:25 AM, Mark Thomas wrote: >>> You need to de-register the driver you registered. However, that >>> won't be causing the leak since Tomcat already did the clean up for >>> you. Time to get the profiler out. >> >> Quick question: I get these JDBC Driver messages from Tomcat when I >> undeploy, but my code does not register the driver itself... > > The code might not, but registration is triggered by the application > including the JAR. Just putting a JAR with a JDBC driver and the > appropriate content in META-INF/services is enough to trigger > registration with the JVM. Tomcat has nothing to do with this. > >> Tomcat does >> via a <Resource> defined in context.xml. Is that driver registered with >> the WebappClassLoader and therefore considered "registered" by the webapp? > > No. It is registered with the DriverManager. It is loaded by the > WebappClassLoader which triggers the potential memory leak. > >> I've been irritated by this behavior for a while because I feel like the >> container is performing the registration of the driver, but expecting >> the webapp to perform the de-registration. > > The META-INF/services mechanism does not provide automatic > de-registration so the app has to take care of it. > > 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
