java - CallableStatement.close() 会导致性能问题

Question

我有一个关于性能的问题。

我开发的应用程序是 Spring MVC 应用程序 (v3.2.9)。它托管在 WebSphere Application Server (v8.5.5) 上。它连接到 AS400 DB2 系统(驱动程序是 JTOpen v9.1)。我的应用程序调用 IBM AS400 系统上的存储过程。它是使用 Spring 的 JdbcTemplate.execute 方法调用的。代码如下:

jdbcTemplate.execute(new CallableStatementCreator() {
        @Override
        public CallableStatement createCallableStatement(Connection con) throws SQLException {
            CallableStatement cs = con.prepareCall("{CALL XXXXXXSP ( ?, ? )}");
            cs.setString(1, xxx);
            cs.setString(2, xxx);
            return cs;
        }
    }, 
    new CallableStatementCallback<String>() {
        @Override
        public String doInCallableStatement(CallableStatement cs)throws SQLException, DataAccessException {
            cs.execute();
            return null;
        }
    });

我们遇到了一些问题，调用此过程偶尔会引发错误“[SQL0501] Cursor C1 not open”打开日志记录并检查后，看起来只有当应用程序尝试重新启动时才会发生此错误- 使用 CallableStatement。上次使用此 CallableStatement 时，相应的游标已关闭，这会导致错误(我不能 100% 确定此重用是否是预期行为)。该错误每天大约发生 20 次，这是一个相对较低的百分比，因为该应用程序的流量要高得多。

我的问题是，在cs.execute();之后的代码中添加cs.close();会导致代码性能下降吗？

Answer 1

一般情况下应该调用close()方法来关闭语句，因为它会释放资源。这没有任何问题。

但是JdbcTemplate为你关闭了声明，所以不需要它。

这是 JdbcTemplate 在执行结束时所做的事情 execute(CallableStatementCreator csc, CallableStatementCallback<T> action)方法:

JdbcUtils.closeStatement(cs);
DataSourceUtils.releaseConnection(con, getDataSource());

来自 CallableStatementCallback api :

 doInCallableStatement(CallableStatement cs) throws SQLException ,DataAccessException

Gets called by JdbcTemplate.execute with an active JDBC CallableStatement. Does not need to care about closing the Statement or the Connection, or about handling transactions: this will all be handled by Spring's JdbcTemplate. NOTE: Any ResultSets opened should be closed in finally blocks within the callback implementation. Spring will close the Statement object after the callback returned, but this does not necessarily imply that the ResultSet resources will be closed: the Statement objects might get pooled by the connection pool, with close calls only returning the object to the pool but not physically closing the resources.