关闭池中的 JDBC 连接

问题描述

我们使用 JDBC 的标准代码部分是...

Our standard code section for using JDBC is...

Connection conn = getConnection(...);
Statement  stmt = conn.conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
                                                ResultSet.CONCUR_READ_ONLY);
ResultSet  rset = stmt.executeQuery (sqlQuery);

// do stuff with rset

rset.close(); stmt.close(); conn.close();

问题 1: 使用连接池时，最后是否应该关闭连接?如果是这样，池化的目的不就丢了吗?如果没有，DataSource 如何知道 Connection 的特定实例何时被释放并可以重用?我对这个有点困惑，任何指点都表示赞赏.

Question 1: When using Connection Pool, should one close the Connection at the end? If so, isn't the purpose of pooling lost? And if not, how does the DataSource know when a particular instance of Connection is freed up and can be reused? I am a little confused on this one, any pointers appreciated.

问题 2: 以下方法是否接近标准?看起来像是尝试从池中获取连接，如果无法建立 DataSource，请使用老式的 DriverManager.我们甚至不确定哪个部分在运行时被执行.重复上面的问题，这种方法出来的Connection是不是应该关闭?

Question 2: Is the following method anything close to standard? Looks like an attempt to get a connection from the pool, and if DataSource cannot be established, use the old fashioned DriverManager. We are not even sure which part is getting executed at runtime.Repeating the question above, should one close the Connection coming out of such a method?

synchronized public Connection getConnection (boolean pooledConnection)
                                                        throws SQLException {
        if (pooledConnection) {
                if (ds == null) {
                        try {
                                Context envCtx = (Context)
                                        new InitialContext().lookup("java:comp/env");
                                ds = (DataSource) envCtx.lookup("jdbc/NamedInTomcat");
                                return ds.getConnection();
                        } catch (NamingException e) {
                                e.printStackTrace();
                }}
                return (ds == null) ? getConnection (false) : ds.getConnection();
        }
        return DriverManager.getConnection(
                "jdbc:mysql://"+ipaddy+":"+dbPort +"/" + dbName, uName, pWord);
}

我认为我们正在获得池连接，因为我们没有看到堆栈跟踪.

I think we are getting the pooled connection since we do not see a stack trace.

推荐答案

是的，当然您也需要关闭池连接.它实际上是实际连接的包装器.它会在幕后将实际连接释放回池.由池进一步决定实际连接是实际上关闭还是重新用于新的 getConnection() 调用.因此，无论您是否使用连接池，您都应该始终在 try 的 finally 块中以相反的顺序关闭所有 JDBC 资源 阻止您获得它们的位置.在 Java 7 中，这可以通过使用 try-with- 进一步简化资源 声明.

Yes, certainly you need to close the pooled connection as well. It's actually a wrapper around the actual connection. It wil under the covers release the actual connection back to the pool. It's further up to the pool to decide whether the actual connection will actually be closed or be reused for a new getConnection() call. So, regardless of whether you're using a connection pool or not, you should always close all the JDBC resources in reversed order in the finally block of the try block where you've acquired them. In Java 7 this can be further simplified by using try-with-resources statement.

以下方法是否接近标准?看起来像是尝试从池中获取连接，如果无法建立 DataSource，请使用老式的 DriverManager.我们甚至不确定哪个部分在运行时被执行.重复上面的问题，这种方法出来的Connection应该关闭吗?

这个例子非常可怕.您只需要在应用程序启动期间在应用程序范围的 DB 配置类的某些构造函数/初始化中查找/初始化 DataSource 一次.然后只需在应用程序的其余生命周期中对同一个数据源调用 getConnection().无需同步或空检查.

The example is pretty scary. You just need to lookup/initialize the DataSource only once during application's startup in some constructor / initialization of an applicationwide DB config class. Then just call getConnection() on the one and same datasource throughout the rest of application's lifetime. No need for synchronization nor nullchecks.

• 在多线程系统中使用静态 java.sql.Connection 实例是否安全?
• 我在使用 JDBC 连接池吗?

这篇关于关闭池中的 JDBC 连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！