commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 12888] - [jelly] JDBC sql result set leak
Date Thu, 26 Sep 2002 20:26:24 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12888>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12888

[jelly] JDBC sql result set leak





------- Additional Comments From steve.downey@netfolio.com  2002-09-26 20:26 -------
That's probably the wrong order. It's usual to close in inverse order from open.

Here's the canonical code for this kind of thing:

  stmt = connection.prepareStatment(something);
  try {
      ResultSet rs = stmt.executeQuery();
      try {
         //do stuff with result set
      } finally {
         rs.close(); 
      }
  } finally {
      stmt.close();
  }

One of the guarantees of JDBC is that the creation methods never return null.
They will throw an exception. So the appropriate pattern to is to use
try{}finally{} directly after creation to clean up. Checks for null in a finally
block at the end of the entire method prove to be error prone under maintenance.

I believe closing a statement without closing the result set could lead to
exceptions, as the result set is attacted to the statement. Although in this
case, it's probably safe.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message