Develop Reference

Resource management in bluemix and explicit closure of prepared statements in JDBC [duplicate]

It is said to be a good habit to close all JDBC resources after usage. But if I have the following code, is it necessary to close the Resultset and the Statement?
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
conn = // Retrieve connection
stmt = conn.prepareStatement(// Some SQL);
rs = stmt.executeQuery();
} catch(Exception e) {
// Error Handling
} finally {
try { if (rs != null) rs.close(); } catch (Exception e) {};
try { if (stmt != null) stmt.close(); } catch (Exception e) {};
try { if (conn != null) conn.close(); } catch (Exception e) {};
}
The question is if the closing of the connection does the job or if it leaves some resources in use.

What you have done is perfect and very good practice.
The reason I say its good practice... For example, if for some reason you are using a "primitive" type of database pooling and you call connection.close(), the connection will be returned to the pool and the ResultSet/Statement will never be closed and then you will run into many different new problems!
So you can't always count on connection.close() to clean up.

Java 1.7 makes our lives much easier thanks to the try-with-resources statement.
try (Connection connection = dataSource.getConnection();
Statement statement = connection.createStatement()) {
try (ResultSet resultSet = statement.executeQuery("some query")) {
// Do stuff with the result set.
}
try (ResultSet resultSet = statement.executeQuery("some query")) {
// Do more stuff with the second result set.
}
}
This syntax is quite brief and elegant. And connection will indeed be closed even when the statement couldn't be created.

From the javadocs:
When a Statement object is closed, its
current ResultSet object, if one
exists, is also closed.
However, the javadocs are not very clear on whether the Statement and ResultSet are closed when you close the underlying Connection. They simply state that closing a Connection:
Releases this Connection object's
database and JDBC resources
immediately instead of waiting for
them to be automatically released.
In my opinion, always explicitly close ResultSets, Statements and Connections when you are finished with them as the implementation of close could vary between database drivers.
You can save yourself a lot of boiler-plate code by using methods such as closeQuietly in DBUtils from Apache.

I'm now using Oracle with Java. Here my point of view :
You should close ResultSet and Statement explicitly because Oracle has problems previously with keeping the cursors open even after closing the connection. If you don't close the ResultSet (cursor) it will throw an error like Maximum open cursors exceeded.
I think you may encounter with the same problem with other databases you use.
Here is tutorial Close ResultSet when finished:
Close ResultSet when finished
Close ResultSet object as soon as you finish
working with ResultSet object even
though Statement object closes the
ResultSet object implicitly when it
closes, closing ResultSet explicitly
gives chance to garbage collector to
recollect memory as early as possible
because ResultSet object may occupy
lot of memory depending on query.
ResultSet.close();

If you want more compact code, I suggest using Apache Commons DbUtils. In this case:
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
conn = // Retrieve connection
stmt = conn.prepareStatement(// Some SQL);
rs = stmt.executeQuery();
} catch(Exception e) {
// Error Handling
} finally {
DbUtils.closeQuietly(rs);
DbUtils.closeQuietly(stmt);
DbUtils.closeQuietly(conn);
}

No you are not required to close anything BUT the connection. Per JDBC specs closing any higher object will automatically close lower objects. Closing Connection will close any Statements that connection has created. Closing any Statement will close all ResultSets that were created by that Statement. Doesn't matter if Connection is poolable or not. Even poolable connection has to clean before returning to the pool.
Of course you might have long nested loops on the Connection creating lots of statements, then closing them is appropriate. I almost never close ResultSet though, seems excessive when closing Statement or Connection WILL close them.

Doesn't matter if Connection is poolable or not. Even poolable connection has to clean before returning to the pool.
"Clean" usually means closing resultsets & rolling back any pending transactions but not closing the connection. Otherwise pooling looses its sense.

The correct and safe method for close the resources associated with JDBC this (taken from How to Close JDBC Resources Properly – Every Time):
Connection connection = dataSource.getConnection();
try {
Statement statement = connection.createStatement();
try {
ResultSet resultSet = statement.executeQuery("some query");
try {
// Do stuff with the result set.
} finally {
resultSet.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}

I created the following Method to create reusable One Liner:
public void oneMethodToCloseThemAll(ResultSet resultSet, Statement statement, Connection connection) {
if (resultSet != null) {
try {
if (!resultSet.isClosed()) {
resultSet.close();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
if (statement != null) {
try {
if (!statement.isClosed()) {
statement.close();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
if (connection != null) {
try {
if (!connection.isClosed()) {
connection.close();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
}
I use this Code in a parent Class thats inherited to all my classes that send DB Queries. I can use the Oneliner on all Queries, even if i do not have a resultSet.The Method takes care of closing the ResultSet, Statement, Connection in the correct order. This is what my finally block looks like.
finally {
oneMethodToCloseThemAll(resultSet, preStatement, sqlConnection);
}

With Java 6 form I think is better to check it is closed or not before close (for example if some connection pooler evict the connection in other thread) - for example some network problem - the statement and resultset state can be come closed. (it is not often happens, but I had this problem with Oracle and DBCP). My pattern is for that (in older Java syntax) is:
try {
//...
return resp;
} finally {
if (rs != null && !rs.isClosed()) {
try {
rs.close();
} catch (Exception e2) {
log.warn("Cannot close resultset: " + e2.getMessage());
}
}
if (stmt != null && !stmt.isClosed()) {
try {
stmt.close();
} catch (Exception e2) {
log.warn("Cannot close statement " + e2.getMessage());
}
}
if (con != null && !conn.isClosed()) {
try {
con.close();
} catch (Exception e2) {
log.warn("Cannot close connection: " + e2.getMessage());
}
}
}
In theory it is not 100% perfect because between the the checking the close state and the close itself there is a little room for the change for state. In the worst case you will get a warning in long. - but it is lesser than the possibility of state change in long run queries. We are using this pattern in production with an "avarage" load (150 simultanous user) and we had no problem with it - so never see that warning message.

Some convenience functions:
public static void silentCloseResultSets(Statement st) {
try {
while (!(!st.getMoreResults() && (st.getUpdateCount() == -1))) {}
} catch (SQLException ignore) {}
}
public static void silentCloseResultSets(Statement ...statements) {
for (Statement st: statements) silentCloseResultSets(st);
}

As far as I remember, in the current JDBC, Resultsets and statements implement the AutoCloseable interface. That means they are closed automatically upon being destroyed or going out of scope.

Tomcat Connection Pool abandoned issue

I'm struggling with a Tomcat connection pool error.The below error is thrown at runtime after running a simple stored procedure that generates a String value.
WARNING: Connection has been abandoned PooledConnection[ConnectionID:45 ClientConnectionId: 7817280c-3f7e-4239-a009-3aedd0a855e8]:java.lang.Exception
at org.apache.tomcat.jdbc.pool.ConnectionPool.getThreadDump(ConnectionPool.java:1096)
at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:799)
at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:648)
at org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:200)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:128)
at util.ThreadLocalUtil.getConnection(ThreadLocalUtil.java:55)
at webapp.dao.WebApplicationDAO.getConnection(WebApplicationDAO.java:30)
at webapp.dao.AccountDAO.generateAccountId(AccountDAO.java:827)
at webapp.bo.Account.generateUserAccountId(Account.java:285)
at webapp.actions.AddUserAccountUNZAction.execute(AddUserAccountUNZAction.java:79)
at org.apache.struts.chain.commands.servlet.ExecuteAction.execute(ExecuteAction.java:58)
at org.apache.struts.chain.commands.AbstractExecuteAction.execute(AbstractExecuteAction.java:67)
at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51)
My knowledge of that error is that a connection was opened and not closed. The connection is opened when running the stored proc in the account dao. Below is the block of code which calls the stored procedure.
Connection conn = null;
CallableStatement stmt = null;
ResultSet rs = null;
try {
conn = getConnection();
stmt = conn.prepareCall(sqlWebAppGenerateUserId);
stmt.setString(1, base);
rs = stmt.executeQuery();
String res = null;
if (rs.next()) {
res = rs.getString(1);
}
if (res == null) {
throw new RuntimeException("Failed to generate user id.");
}
return res;
} catch (SQLException e) {
LOG.error("{}", e);
throw new RuntimeException(e);
}finally {
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
LOG.error(e.getMessage(), e);
}
}
if (rs != null) {
try {
rs.close();
conn.close();
} catch (SQLException e) {
LOG.error(e.getMessage(), e);
}
}
}
As you can see, I'm using a finally block to close the connection etc.
I'm at a loss to explain the reason why the error is being thrown still and as to how I can debug and solve this issue. Any help would be greatly appreciated

You close conn only if rs != null, meaning that every time a query fails the connection won't be closed.
I also recommend switching to try-with-resources instead of writing clumsy finally blocks which may cause bugs.

What #Kayaman said. Also if the statement execution takes longer than removeAbandonedTimeout this can happen.

#Kayaman and #Gorazd thank you for the advice. The issue with down to missing jar files in the tomcat lib folder. More specifically mail-1.4.jar.
As this jar file was missing, a function that sends emails failed. Previous to the call to send the mail, connection.autocommit is set to true. After the mail sends it will set autocommit back to false. This to me looks like where the abandoned error was occurring from.
When looking through logs file I found the mail sending error. This was in actual fact the true error whereas the abandoned error can be looked at as a red herring.

Insert Data In Oracle DataBase

//in context listener
Statement stmt;
try {
Class.forName("oracle.jdbc.OracleDriver");
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:#127.0.0.1:1521:orcl","abc", "abc");
stmt = conn.createStatement();
sce.getServletContext().setAttribute("stmt", stmt);
} catch (ClassNotFoundException e) {
} catch (SQLException e) {
}
//in Servlet page
try {
Statement stmts=(Statement) getServletContext().getAttribute("stmt");
stmts.executeUpdate("INSERT INTO COMPANYS values(1,'ahmed',5,'t012','t345','email#eamil','adressadress')");
System.out.println("connection succeed");
} catch (SQLException e) {
System.out.println("connection fail");
}
in Servlet page "try code" is execute and "connection succeed" is appearing but in oracle database there is no data inserted >> why???

use con.setAutoCommit(false); after conn has created. Once the transaction completes i.e.,after executeUpdate(...) call con.commit(); It will solve your issue if their are no errors displayed on the console.

Try it again with below steps
Set auto commit as false
Commit after updating the record to make it persisted in the database
Rollback if there is any exception while inserting the record
Don't forget to clean-up the environment such as ResultSet, Statement etc.
Code in finally block to close the resources
Don't keep connection opened for long time.
Must read
Is it mandatory to close all ResultSets, Statements and Connections?
Java Tutorial - Using Transactions
Find a sample code HERE with detailed inline comments.

automatic closing of result-set in Java SQL

Consider the following code
ResultSet rs = null;
Statement st = null;
try {
//do somehting
} catch (Exception e){
//do something
} finally {
if(st != null){
try {
st.close();
} catch (SQLException e) {
log.error("Exception while closing statement: " + e);
}
}
}
The question is that when we close the statement, will it close the result set as well or do we need to explicitly close the result set like this
if(rs != null){
try {
rs.close();
} catch (SQLException e) {
log.error("Exception while closing result set: " + e);
}
}
I thought that closing the statement will automatically close the result set, but FindBugs throws the following warning if I don't explicitly close the result set
This method may fail to clean up java.sql.ResultSet

When a Statement object is closed, its current ResultSet object, if one exists, is also closed.
This and this shows that Oracle may have problems and you might have to explicitly close the ResultSet. But again, as per the Javadocs, this shouldn't be an issue. Hence, the warning,maybe.

You can't count on the ResultSet being closed automatically, it depends on the driver implementation and how compliant it is. The best policy is to close the ResultSet explicitly.

When you close the statement or connection, all it's children should be closed too by default.

Java 7 Automatic Resource Management JDBC (try-with-resources statement)

How to integrate the common JDBC idiom of creating/receiving a connection, querying the database and possibly processing the results with Java 7's automatic resource management, the try-with-resources statement? (Tutorial)
Before Java 7, the usual pattern was something like this:
Connection con = null;
PreparedStatement prep = null;
try{
con = getConnection();
prep = prep.prepareStatement("Update ...");
...
con.commit();
}
catch (SQLException e){
con.rollback();
throw e;
}
finally{
if (prep != null)
prep.close();
if (con != null)
con.close();
}
With Java 7 you can go for:
try(Connection con = getConnection(); PreparedStatement prep = con.prepareConnection("Update ..."){
...
con.commit();
}
This will close the Connection and the PreparedStatement, but what about the rollback? I cannot add a catch clause containing the rollback, because the connection is only available within the try block.
Do you still define the connection outside of the try block? What is the best practice here, especially if connection pooling is used?

try(Connection con = getConnection()) {
try (PreparedStatement prep = con.prepareConnection("Update ...")) {
//prep.doSomething();
//...
//etc
con.commit();
} catch (SQLException e) {
//any other actions necessary on failure
con.rollback();
//consider a re-throw, throwing a wrapping exception, etc
}
}
According to the oracle documentation, you can combine a try-with-resources block with a regular try block. IMO, the above example captures the correct logic, which is:
Attempt to close the PreparedStatement if nothing goes wrong
If something goes wrong in the inner block, (no matter what is is) roll back the current transaction
Attempt to close the connection no matter what
If something goes wrong closing the connection, you can't rollback the transaction (as that's a method on the connection, which is now in indeterminate state), so don't try
In java 6 and earlier, I would do this with a triply nested set of try blocks (outer try-finally, middle try-catch, inner try-finally). ARM syntax does make this terser.

IMO, declaring Connection and PreparedStatement outside try-catch is the best way available in this case.

If you want to use pooled connection in transaction, you should use it in this way:
try (Connection conn = source.getConnection()) {
conn.setAutoCommit(false);
SQLException savedException = null;
try {
// Do things with connection in transaction here...
conn.commit();
} catch (SQLException ex) {
savedException = ex;
conn.rollback();
} finally {
conn.setAutoCommit(true);
if(savedException != null) {
throw savedException;
}
}
} catch (SQLException ex1) {
throw new DataManagerException(ex1);
}
This sample code handles setting autocommit values.
NOTE, that using savedException does save exception in case that conn.rollback() throws another. This way, finally block will throw "right" exception.