registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister

zhangxinba

异常如下：
严重: The web application [] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
2011-1-17 14:57:03 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
严重: The web application [] registered the JBDC driver [org.apache.derby.jdbc.ClientDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
2011-1-17 14:57:03 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
严重: The web application [] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak.
2011-1-17 14:57:03 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

这个主要是DBCP的bug在如下链接中已经提出：
https://issues.apache.org/jira/browse/DBCP-332
BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
I was able to fix it by overriding close method this way:
public class XBasicDataSource extends BasicDataSource {
@Override
public synchronized void close() throws SQLException {
DriverManager.deregisterDriver(DriverManager.getDriver(url));
super.close();
}
}

but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.