When in doubt I close ... When working with transactions, I get exceptions if one PreparedStatement is not explictly closed before the executing the next statement in the transaction.
I have also been bitten by forgetting to close connections. Also had problems with connection pools not working correctly (eg using MySQL) and not releasing the connections back to the pool. Explictly closing is always good. Of course it is easy to get carried away and close things before the application is really done with the resource ... Conrad Original Message: ----------------- From: Kenneth Sizer [EMAIL PROTECTED] Date: Wed, 23 Jun 2004 09:58:45 -0400 To: [EMAIL PROTECTED] Subject: RE: [Juglist] Should I explicitly close ResultSet and Statements? It is good practice, IMHO, to close what you open, but it's importance depends on the database. Most engines "do the right thing" when the connection is closed, but in some cases, I have seen crippling memory leaks on the database server when ResultSets are not explicitly closed. --Ken > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tony Spencer > Sent: Wednesday, June 23, 2004 9:45 AM > To: 'Research Triangle Java User's Group mailing list.' > Subject: [Juglist] Should I explicitly close ResultSet and Statements? > > > Is it necessary to close a ResultSet and PreparedStatement at > the end of some JDBC code before closing the Connection or > are they closed automatically by closing the database connection? > > For example is this ok? > > Connection conn = DbPool.getConnection(); > ResultSet rs = null; > PreparedStatement = null; > . > . > . > conn.close(); > > > Or should I do this? > > Connection conn = DbPool.getConnection(); > ResultSet rs = null; > PreparedStatement = null; > . > . > . > rs.close(); > stmnt.close(); > conn.close(); > -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
