我们使用JDBC的标准代码部分是…
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的特定实例并可以重用?我对此感到有些困惑,任何指针都表示赞赏。
问题2:以下方法是否接近标准?看起来像是尝试从池中获取连接,并且如果无法建立DataSource,请使用老式的DriverManager。我们甚至不确定哪个部分在运行时执行。重复以上问题,是否应该关闭这种方法产生的连接?
谢谢-MS
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); }
编辑:我认为我们正在得到池连接,因为我们没有看到堆栈跟踪。
使用连接池时,应该最后关闭连接吗? 如果是这样,合并的目的就不会丢失吗?如果不是,那么DataSource如何知道何时释放Connection的特定实例并可以重用?我对此感到有些困惑,任何指针都表示赞赏。
是的,当然您也需要关闭池化连接。实际上,它是围绕实际连接的包装。它会在幕后将实际连接释放回池中。由池进一步决定实际的连接 是实际上 是关闭还是重新用于新getConnection()呼叫。因此,无论是否使用连接池,都应 始终 以相反的顺序在获取它们finally的try块中关闭所有JDBC资源。在Java 7中,可以通过使用try-with- resourcesstatement 进一步简化此操作。
getConnection()
finally
try
try-with- resources
以下方法是否接近标准? 看起来像是尝试从池中获取连接,并且如果无法建立DataSource,请使用老式的DriverManager。我们甚至不确定哪个部分在运行时执行。重复以上问题,是否应该关闭这种方法产生的连接?
这个例子很吓人。您只需要DataSource在应用程序启动期间在整个应用程序范围的数据库配置类的某些构造函数/初始化中查找/初始化一次。然后,只需getConnection()在应用程序的整个生命周期中调用一个相同的数据源即可。不需要同步也不需要nullcheck。
DataSource