I wrote a booch utility class (fancy name for static methods...) It has a whole lot of overloaded (Connection, PreparedStatement, Statement, ResultSet etc) methods like this... (LOGGER is a JDK1.4 logger)
public static void closeJDBCResource(ResultSet rs) { try { if (rs != null) { rs.close(); } } catch (SQLException e) { LOGGER.log(Level.FINE, e.getLocalizedMessage(), e); } } Simplifying (probably over simplifying, I don't see the point in unnecessary duplication or nulling local variables) Craig's code down to... Connection conn = null; Statement stmt = null; // Or PreparedStatement if needed ResultSet rs = null; try { conn = ... get connection from connection pool ... stmt = conn.createStatement("select ..."); rs = stmt.executeQuery(); ... iterate through the result set ... } catch (SQLException e) { ... deal with errors ... } finally { closeJDBCResource(rs); closeJDBCResource(stmt); closeJDBCResource(conn); } Glenn Nielsen wrote: > Hmm, this example code should get added to the Tomcat > JNDI-DataSource-HOWTO. :-) > > Craig R. McClanahan wrote: > >> >> On Tue, 27 Aug 2002, Short, Dave wrote: >> >> >>> Date: Tue, 27 Aug 2002 09:08:58 -0700 >>> From: "Short, Dave" <[EMAIL PROTECTED]> >>> Reply-To: Tomcat Users List <[EMAIL PROTECTED]> >>> To: 'Tomcat Users List' <[EMAIL PROTECTED]> >>> Subject: RE: Does closing a Connection variable and setting it to null >>> clo se all of the ResultSet and Statements? >>> >>> By closing you mean set the ResultSet and Statement objects to null - >>> correct? >>> >> >> >> No ... explicitly call close() on them first. My most common pattern >> for >> JDBC calls goes like this: >> >> Connection conn = null; >> Statement stmt = null; // Or PreparedStatement if needed >> ResultSet rs = null; >> try { >> conn = ... get connection from connection pool ... >> stmt = conn.createStatement("select ..."); >> rs = stmt.executeQuery(); >> ... iterate through the result set ... >> rs.close(); >> rs = null; >> stmt.close(); >> stmt = null; >> conn.close(); // Return to connection pool >> conn = null; >> } catch (SQLException e) { >> ... deal with errors ... >> } finally { >> if (rs != null) { >> try { rs.close(); } catch (SQLException e) { ; } >> rs = null; >> } >> if (stmt != null) { >> try { stmt.close(); } catch (SQLException e) { ; } >> stmt = null; >> } >> if (conn != null) { >> try { conn.close(); } catch (SQLException e) { ; } >> conn = null; >> } >> } >> >> This way, you always clean up after yourself as quickly as possible, and >> never forget to return the connection to the connection pool -- even if >> exceptions occur. >> >> Craig >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>