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]>

Reply via email to