When using a PreparedStatement in JDBC, should I close the PreparedStatement first or the Connection first? I just saw a code sample in which the Connection is closed first, but it seems to me more logical to close the PreparedStatement first.
Is there a standard, accepted way to do this? Does it matter? Does closing the Connection also cause the PreparedStatement to be closed, since the PreparedStatement is directly related to the Connection object?
Closing PreparedStatement ObjectIf you close the Connection object first, it will close the PreparedStatement object as well. However, you should always explicitly close the PreparedStatement object to ensure proper cleanup.
If you want to explicitly close them in a row then you need to close them in the reverse order of creation: ResultSet, Statement, Connection.
At the end of your JDBC program, it is required explicitly to close all the connections to the database to end each database session. However, if you forget, Java's garbage collector will close the connection when it cleans up stale objects.
If you don't close it, it leaks, and ties up server resources. @EJP The connection itself might be thread-safe (required by JDBC), but the applications use of the connection is probably not threadsafe.
The statement. I would expect you to close (in order)
(and check for nulls along the way!)
i.e. close in reverse order to the opening sequence.
If you use Spring JdbcTemplate (or similar) then that will look after this for you. Alternatively you can use Apache Commons DbUtils and DbUtils.close() or DbUtils.closeQuietly().
The following procedures should be done (in order)
ResultSet PreparedStatement Connection.Also, it's advisable to close all JDBC related objects in the finally close to guarantee closure.
//Do the following when dealing with JDBC. This is how I've implemented my JDBC transactions through DAO.... Connection conn = null; PreparedStatement ps = null; ResultSet rs = null; try { conn = .... ps = conn.prepareStatement(...); //Populate PreparedStatement rs = ps.executeQuery(); } catch (/*All relevant exceptions such as SQLException*/Exception e) { logger.error("Damn, stupid exception: " , e); } finally { if (rs != null) { try { rs.close(); rs = null; } catch (SQLException e) { logger.error(e.getMessage(), e.fillInStackTrace()); } } if (ps != null) { try { ps.close(); ps = null; } catch (SQLException e) { logger.error(e.getMessage(), e.fillInStackTrace()); } } try { if (conn!= null && !conn.isClosed()){ if (!conn.getAutoCommit()) { conn.commit(); conn.setAutoCommit(true); } conn.close(); conn= null; } } catch (SQLException sqle) { logger.error(sqle.getMessage(), sqle.fillInStackTrace()); } } You can see I've checked if my objects are null and for connection, check first if the connection is not autocommited. Many people fail to check it and realise that the transaction hasn't been committed to DB.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With