You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Short, Dave" <da...@pfizer.com> on 2002/08/27 18:08:58 UTC
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?
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: August 27, 2002 9:06 AM
To: Tomcat Users List
Subject: Re: Does closing a Connection variable and setting it to null
close all of the ResultSet and Statements?
On Tue, 27 Aug 2002, Tim Funk wrote:
> Date: Tue, 27 Aug 2002 12:03:18 -0400
> From: Tim Funk <fu...@joedog.org>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Does closing a Connection variable and setting it to null
> close all of the ResultSet and Statements?
>
> It is not requried to close ResultSets, Statements, etc if you close the
> connection. (I think) The spec says if you close a connection - all
> associated resources for that connection will also be closed.
>
That's what the spec says, but relying on it is being awfully trusting of
JDBC driver developers to do the right thing. A little paranoia here
(i.e. close the result sets and statements yourself) goes a long way
towards making your apps more reliable.
Craig
> If you are using a pool - the pool manager *should* be obeying this
> principal too.
>
> Michael Nicholson wrote:
> > Well, I guess the subject line says it all. I'm having memory issues,
and having read the OOM error messages on the list, I've checked and found
some open and not being closed connections, so I'm going back and closing
them all. The question is do I need to explicitly close/dereference (set to
null) all statements and recordsets too? Right now the system takes about
4% of my available memory just for the beans in question, so I'm trying to
minimize what I store so that I could conceptually have more than one user.
> >
> > Thanks in advance,
> > Mike Nicholson
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Does closing a Connection variable and setting it to null close all of the ResultSet and Statements?
Posted by Andrew Conrad <an...@attbi.com>.
No, you should invoke .close() on your resultset and statement object.
Setting to null is also a good idea, but not as important as closing the
objects.
- Andrew
> -----Original Message-----
> From: Short, Dave [mailto:dave.short@pfizer.com]
> Sent: Tuesday, August 27, 2002 12:09 PM
> To: 'Tomcat Users List'
> Subject: RE: Does closing a Connection variable and setting
> it to null close all of the ResultSet and Statements?
>
>
> By closing you mean set the ResultSet and Statement objects
> to null - correct?
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: August 27, 2002 9:06 AM
> To: Tomcat Users List
> Subject: Re: Does closing a Connection variable and setting
> it to null close all of the ResultSet and Statements?
>
>
>
>
> On Tue, 27 Aug 2002, Tim Funk wrote:
>
> > Date: Tue, 27 Aug 2002 12:03:18 -0400
> > From: Tim Funk <fu...@joedog.org>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > Subject: Re: Does closing a Connection variable and setting
> it to null
> > close all of the ResultSet and Statements?
> >
> > It is not requried to close ResultSets, Statements, etc if
> you close
> > the connection. (I think) The spec says if you close a connection -
> > all associated resources for that connection will also be closed.
> >
>
> That's what the spec says, but relying on it is being awfully
> trusting of JDBC driver developers to do the right thing. A
> little paranoia here (i.e. close the result sets and
> statements yourself) goes a long way towards making your apps
> more reliable.
>
> Craig
>
>
> > If you are using a pool - the pool manager *should* be obeying this
> > principal too.
> >
> > Michael Nicholson wrote:
> > > Well, I guess the subject line says it all. I'm having memory
> > > issues,
> and having read the OOM error messages on the list, I've
> checked and found some open and not being closed connections,
> so I'm going back and closing them all. The question is do I
> need to explicitly close/dereference (set to
> null) all statements and recordsets too? Right now the
> system takes about 4% of my available memory just for the
> beans in question, so I'm trying to minimize what I store so
> that I could conceptually have more than one user.
> > >
> > > Thanks in advance,
> > > Mike Nicholson
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Does closing a Connection variable and setting it to null clo
se all of the ResultSet and Statements?
Posted by Ben Walding <be...@walding.com>.
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" <da...@pfizer.com>
>>> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>> To: 'Tomcat Users List' <to...@jakarta.apache.org>
>>> 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:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Does closing a Connection variable and setting it to null clo
se all of the ResultSet and Statements?
Posted by Glenn Nielsen <gl...@mail.more.net>.
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" <da...@pfizer.com>
>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>To: 'Tomcat Users List' <to...@jakarta.apache.org>
>>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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Does closing a Connection variable and setting it to null clo
se all of the ResultSet and Statements?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 27 Aug 2002, Short, Dave wrote:
> Date: Tue, 27 Aug 2002 09:08:58 -0700
> From: "Short, Dave" <da...@pfizer.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: 'Tomcat Users List' <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>