[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    DO NOT REPLY [Bug 12888]  -
From:       bugzilla () apache ! org
Date:       2002-09-30 17:35:29
[Download RAW message or body]

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 jstrachan@apache.org  2002-09-30 17:35 -------
Thanks for your comments Kevin and Steve!

I've patched the code so that the result set is closed first, then the 
statement, then the connection. (Note if a connection pool is being used then 
the connection isn't really closed).

I'm assuming that in a JDBC 2 versus 3 world, the driver will (say) when the 
statement is closed it will only attempt to close the result set if its not 
already closed etc. So hopefully this extra closing code won't cause new 
problems.


If an exception occurs while normally closing the result set or statement, then 
its thrown. Otherwise if another exception is thrown (maybe not even an SQL 
related one) then any exceptions thrown by closing the result set or statement 
will be caught.



Using Steve's pseudocode example its something like this...

  stmt = connection.prepareStatment(something);
  try {
      rs = stmt.executeQuery();
      rs.close(); 
      statement.close();
  }
  finally {
      // catch any exceptions thrown inside this block...
      if (not closed already) {
        rs.close();
      if (not closed already) {
        stmt.close();
  }

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

[prev in list] [next in list] [prev in thread] [next in thread]