Thewebapplication[]registeredtheJDBCdriver[com.mysql.jdbc.Driver]butfailedtounregister

声明&＃xff1a;本文转自mtgongren的博客&＃xff0c;如有需要&＃xff0c;请联系本作者。谢谢&＃xff01;

暑假的时候做了一个项目&＃xff0c;用的是SSH&＃43;MySQL5.0&＃43;tomcat5.5

做完部署到服务器后&＃xff08;tomcat是6.0.32&＃xff09;&＃xff0c;测试正常运行。第二天发现无法登录了&＃xff0c;检查了一遍系统没发现什么问题&＃xff0c;重启tomcat后又恢复正常了。
很奇怪&＃xff0c;于是查看tomcat的日志&＃xff0c;发现如下问题&＃xff1a;

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驱动&＃xff0c;但当程序停止时无法注销这个驱动&＃xff0c;tomcat为了防止内存溢出&＃xff0c;就给强制注销了。
上网搜&＃xff0c;发现网上有不少关于这个问题的讨论&＃xff0c;说是DBCP的bug。

详细如下&＃xff1a;
https://issues.apache.org/jira/browse/DBCP-332

Description

BasicDataSource&＃39;s method close() doesn&＃39;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:




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版本之后引入了内存泄漏侦测的功能&＃xff0c;当发现系统有垃圾无法回收时&＃xff0c;就会输出日志信息。

看了很多关于这个问题的讨论&＃xff0c;好像也没发现什么好的解决方法。有的说把tomcat的内存监听器关了就不会报这个异常&＃xff0c;可是不报不等于没问题&＃xff0c;依然无法解决啊。感觉应该是Hibernate的默认连接池对数据库连接的管理存在bug&＃xff0c;其不会对连接是否有效进行检查&＃xff0c;所以会出现异常。

在网上搜了关于Hibernate配置MySQL的资料&＃xff0c;发现Mysql有个8小时问题&＃xff0c;即系统如果超过8个小时没有被访问&＃xff0c;mysql就会关闭空闲的Connection连接&＃xff0c;而hibernate不会对连接是否有效进行检查&＃xff0c;导致系统无法连接数据库。

在看了很多资料后&＃xff0c;基本上可以确定是数据库连接的管理出了问题&＃xff0c;用的是Hibernate3&＃xff0c;配置数据库的时候用的是Hibernate默认的连接池&＃xff0c;尝试更换成了Proxool连接池。

参考如下&＃xff1a;


http://www.360doc.com/content/08/0101/10/53523_938529.shtml



3. proxool连接池



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



hibernate.cfg.xml








在hibernate.cfg.xml的同目录下编写proxool的配置文件&＃xff1a;ProxoolConf.xml&＃xff0c;该文件的配置实例如下&＃xff1a;



ProxoolConf.xml










按照上面讲的加入了Proxool0.9.1的jar包并配置好了&＃xff0c;测试时却不通过&＃xff0c;报没有jdbc connection的异常&＃xff0c;奇怪。一个哥们和我一起按照上面的配置&＃xff0c;他的却通过了&＃xff0c;看了他的配置文件发现他的hibernate.cfg.xml里依然配置有数据库的连接信息&＃xff0c;这个应该不需要了&＃xff0c;因为在Proxool.xml里配置了啊。难道是因为这个&＃xff0c;我也加上连接信息进行测试&＃xff0c;结果正常登录&＃xff0c;把系统日期往后调了几天再进行登录测试&＃xff0c;又报了一开始的那个异常。很明显我配的这个连接池没有起作用&＃xff0c;很奇怪。我哥们把他的Hibernate.cfg.xml里的数据库连接配置去掉后&＃xff0c;他的依然可以运行通过&＃xff0c;而且系统调时间后也可以运行&＃xff0c;说明这个连接池起作用了&＃xff0c;问题终于算是解决了&＃xff0c;很高兴。可是我们的代码是一样的&＃xff0c;对比了各自的配置文件也都是一样的啊&＃xff0c;为什么在我这不起作用呢&＃xff1f;很是郁闷&＃xff0c;难道是人品的问题&＃xff1f;&＃xff01;不会的&＃xff0c;我人品应该还可以啊&＃xff0c;可是残酷的现实就摆在眼前。。。。。。不管了&＃xff0c;都中午一点多了&＃xff0c;午饭还没吃呢&＃xff0c;去吃饭。

在学校外面的兰州拉面馆吃了碗牛肉刀削面&＃xff0c;回来后还是想着这个问题&＃xff0c;搁心里憋的慌。想了一会&＃xff0c;觉得应该还是Hibernate.cfg.xml和proxool.xml配置文件的问题&＃xff0c;于是我把哥们的这两个配置文件拷贝到我的系统里&＃xff0c;把我的替换掉。运行通过。。。。。。晕死&＃xff0c;配置文件的内容是我直接拷贝网页上的&＃xff0c;可能存在一些字符问题。这样测试还是不放心&＃xff0c;又把系统放到了一个小服务器上跑段时间看还会不会出现问题。

结果跑了几天后&＃xff0c;依然正常。