点击打开链接
数据库应用开发过程中,我们可能会遇到一个问题:应用使用了数据库连接池,每经过指定时间后,发出到数据库服务器的任何请求都会失败,而且有且仅有一次失败,之后的正常访问都没有问题。尤其是在Web应用中,如果晚上时段没有访问,而第二天第一个访客的经历就是碰到一个数据库访问错误,如果开发系统的程序员没有注意这个问题的话,可能终端用户访问会看到抛出的一堆数据库异常信息。
其实,这个问题的主要原因是,应用中数据库连接池中会保存指定数量的数据库连接实例,而这些连接实例并没有定时地检测其到数据库服务器连接是否正常;数据库服务器可以配置一个数据库连接实例的超时时间,超过时间后它会自动断开连接。也就是,被断开的那个连接此时仍然保存在应用的数据库连接池内,下次被使用的时候就会发生数据库连接断开而导致一次访问失败。
解决上述连接关闭的方案有两种值得推荐:
- 如果能够提供这样一种检测机制,在应用的连接池管理中定时地检测连接池中连接的有效性,就完全可以避免上面描述的问题。
- 在应用代码中通过异常处理机制,来实现该次业务的重新处理,也可以很好地避免。
我们举一个例子,使用Java开发的Web系统,Tomcat作为HTTP服务器,MySQL作为数据库,抛出异常的信息如下所示:
- [http-bio-8080-exec-10] 2012-11-28 00:55:43 [org.shirdrn.wm.de.action.StatAction]-[WARN]
- com.ibatis.dao.client.DaoException: Error ending SQL Map transaction. Cause: java.sql.SQLException: Already closed.
- at com.ibatis.dao.engine.transaction.sqlmap.SqlMapDaoTransaction.rollback(SqlMapDaoTransaction.java:51)
- at com.ibatis.dao.engine.transaction.sqlmap.SqlMapDaoTransactionManager.rollbackTransaction(SqlMapDaoTransactionManager.java:85)
- at com.ibatis.dao.engine.impl.DaoContext.endTransaction(DaoContext.java:112)
- at com.ibatis.dao.engine.impl.DaoProxy.invoke(DaoProxy.java:77)
- at $Proxy8.selectByExample(Unknown Source)
- at org.shirdrn.wm.de.service.impl.StatItemsServiceImpl.countItems(Unknown Source)
- at org.shirdrn.wm.de.action.StatAction.makeStat(Unknown Source)
- at org.shirdrn.wm.de.action.StatAction.doGet(Unknown Source)
- at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
- at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
- at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
- at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
- at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
- at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
- at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
- at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
- at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
- at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
- at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
- at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
- at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
- at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
- at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
- at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
- at java.lang.Thread.run(Thread.java:619)
- Caused by: java.sql.SQLException: Already closed.
- at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:84)
- at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:181)
- at com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.close(JdbcTransaction.java:81)
- at com.ibatis.sqlmap.engine.transaction.TransactionManager.end(TransactionManager.java:93)
- at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.endTransaction(SqlMapExecutorDelegate.java:734)
- at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.endTransaction(SqlMapSessionImpl.java:176)
- at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.endTransaction(SqlMapClientImpl.java:153)
- at com.ibatis.dao.engine.transaction.sqlmap.SqlMapDaoTransaction.rollback(SqlMapDaoTransaction.java:49)
- ... 25 more
我们通过上面给出的第二种方案来解决,对应异常中实现的代码,进行异常处理的逻辑如下所示:
- protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
- boolean retry = false;
- String type = request.getParameter(RequestParams.ITEM_TYPE);
- String top = request.getParameter(RequestParams.TOP_N);
- Byte itemType = Byte.parseByte(type);
- Integer topN = super.topN;
- if(top!=null) {
- try {
- topN = Integer.parseInt(top);
- } catch (Exception e) {}
- }
- Target target = itemNames.get(itemType);
- try {
- makeStat(request, response, itemType, topN, target);
- } catch (Exception e) {
- LOG.warn("", e);
-
- if(!retry && e instanceof DaoException) {
- LOG.warn("Try to obtain database connection again.");
- retry = true;
- this.makeStat(request, response, itemType, topN, target);
- } else {
- response.sendError(500, e.toString());
- return;
- }
- }
- request.getRequestDispatcher(target.url).forward(request, response);
- }
-
- private void makeStat(HttpServletRequest request, HttpServletResponse response,
- Byte itemType, Integer topN, Target target) throws IOException, ServletException {
- List<StatItems> items = statItemsService.countItems(itemType, new Date(), topN);
- for (StatItems statK : items) {
- if(statK.getItemName()!=null && !"null".equalsIgnoreCase(statK.getItemName())) {
- pieDataset.setValue(statK.getItemName().trim() + " (" + statK.getPercentage() + ")", statK.getItemValue());
- }
- }
- String imageUrl = super.generateImage(pieDataset, target.title, request);
- request.setAttribute("items", items);
- request.setAttribute("imageUrl", imageUrl);
- if(items!=null && !items.isEmpty() && items.size()<topN) {
- topN = items.size();
- }
- request.setAttribute("topN", topN);
- }
上面代码,判断如果是发生连接失败,则保存请求参数,再重新处理该请求。
另一种不推荐的方案,就是修改数据库服务器的连接超时配置。因为在实际项目中,通常应用上线的相关人员未必是DBA,对于修改数据库服务器的配置可能会给其它上线业务带来风险。解决方法如下:
以MySQL为例,查看文件/etc/my.cnf,查询有关超时配置的参数:
- mysql> show variables like '%timeout';
- +----------------------------+----------+
- | Variable_name | Value |
- +----------------------------+----------+
- | connect_timeout | 10 |
- | delayed_insert_timeout | 300 |
- | innodb_lock_wait_timeout | 50 |
- | innodb_rollback_on_timeout | OFF |
- | interactive_timeout | 28800 |
- | lock_wait_timeout | 31536000 |
- | net_read_timeout | 30 |
- | net_write_timeout | 60 |
- | slave_net_timeout | 3600 |
- | wait_timeout | 28800 |
- +----------------------------+----------+
我们可以在属性组mysqld下面修改如下两个参数:
- interactive_timeout
- wait_timeout
MySQL数据库服务器配置的连接超时时间默认是8小时,如果修改的超时时间足够长的话,就不会出现前面发生的连接断开的问题。但是,如果有很多应用都在使用数据库连接池,大量的数据库连接资源一直被占用,严重的话可能使数据库服务器宕机,而且,也会使一些攻击者伪造大量请求,使数据库服务器负荷过载而宕机,从而影响应用处理业务。