The web application [] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister i

暑假的时候做了一个项目，用的是SSH+MySQL5.0+tomcat5.5
做完部署到服务器后（tomcat是6.0.32），测试正常运行。第二天发现无法登录了，检查了一遍系统没发现什么问题，重启tomcat后又恢复正常了。
很奇怪，于是查看tomcat的日志，发现如下问题：

2011-9-1 0:15:11 org.apache.catalina.startup.Catalina start
信息: Server startup in 35866 ms
2011-9-1 2:05:43 org.apache.coyote.http11.Http11Protocol pause
信息: Pausing Coyote HTTP/1.1 on http-8080
2011-9-1 2:05:44 org.apache.catalina.core.StandardService stop
信息: Stopping service Catalina
2011-9-1 2:05:44 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
严重: The web application [] registered the JDBC 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-9-1 2:05:45 org.apache.coyote.http11.Http11Protocol destroy
信息: Stopping Coyote HTTP/1.1 on http-8080

看报的异常信息是应用程序注册了JDBC驱动，但当程序停止时无法注销这个驱动，tomcat为了防止内存溢出，就给强制注销了。
上网搜，发现网上有不少关于这个问题的讨论，说是DBCP的bug。

详细如下：
https://issues.apache.org/jira/browse/DBCP-332

Description

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.

我的系统没有用spring配置数据源。

tomcat从6.0.24版本之后引入了内存泄漏侦测的功能，当发现系统有垃圾无法回收时，就会输出日志信息。

看了很多关于这个问题的讨论，好像也没发现什么好的解决方法。有的说把tomcat的内存监听器关了就不会报这个异常，可是不报不等于没问题，依然无法解决啊。感觉应该是Hibernate的默认连接池对数据库连接的管理存在bug，其不会对连接是否有效进行检查，所以会出现异常。
在网上搜了关于Hibernate配置MySQL的资料，发现Mysql有个8小时问题，即系统如果超过8个小时没有被访问，mysql就会关闭空闲的Connection连接，而hibernate不会对连接是否有效进行检查，导致系统无法连接数据库。
在看了很多资料后，基本上可以确定是数据库连接的管理出了问题，用的是Hibernate3，配置数据库的时候用的是Hibernate默认的连接池，尝试更换成了Proxool连接池。
参考如下：
http://www.360doc.com/content/08/0101/10/53523_938529.shtml

3. proxool连接池

       proxool跟c3p0以及dbcp不一样，它是自己生成连接的，因此连接信息放在proxool配置文件中。使用它时，需要将proxool-0.8.3.jar加入到classespath中。配置举例如下：

hibernate.cfg.xml

        

        true

        

        net.sf.hibernate.dialect.MySQLDialect



       pool1

ProxoolConf.xml

net.sf.hibernate.connection.ProxoolConnectionProvider

       

       



  

在hibernate.cfg.xml的同目录下编写proxool的配置文件：ProxoolConf.xml，该文件的配置实例如下：

ProxoolConf.xml

pool1






… 



… 











90000

20

5

100

10

按照上面讲的加入了Proxool0.9.1的jar包并配置好了，测试时却不通过，报没有jdbc connection的异常，奇怪。一个哥们和我一起按照上面的配置，他的却通过了，看了他的配置文件发现他的hibernate.cfg.xml里依然配置有数据库的连接信息，这个应该不需要了，因为在Proxool.xml里配置了啊。难道是因为这个，我也加上连接信息进行测试，结果正常登录，把系统日期往后调了几天再进行登录测试，又报了一开始的那个异常。很明显我配的这个连接池没有起作用，很奇怪。我哥们把他的Hibernate.cfg.xml里的数据库连接配置去掉后，他的依然可以运行通过，而且系统调时间后也可以运行，说明这个连接池起作用了，问题终于算是解决了，很高兴。可是我们的代码是一样的，对比了各自的配置文件也都是一样的啊，为什么在我这不起作用呢？很是郁闷，难道是人品的问题？！不会的，我人品应该还可以啊，可是残酷的现实就摆在眼前。。。。。。不管了，都中午一点多了，午饭还没吃呢，去吃饭。
在学校外面的兰州拉面馆吃了碗牛肉刀削面，回来后还是想着这个问题，搁心里憋的慌。想了一会，觉得应该还是Hibernate.cfg.xml和proxool.xml配置文件的问题，于是我把哥们的这两个配置文件拷贝到我的系统里，把我的替换掉。运行通过。。。。。。晕死，配置文件的内容是我直接拷贝网页上的，可能存在一些字符问题。这样测试还是不放心，又把系统放到了一个小服务器上跑段时间看还会不会出现问题。
结果跑了几天后，依然正常。