Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <298105621.553351269879387251.JavaMail.jira@brutus.apache.org>
Date: Mon, 29 Mar 2010 16:16:27 +0000 (UTC)
From: "Hontvari Jozsef (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (DBCP-329) SQLException: Already closed.
In-Reply-To: <317396024.537351269807447218.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850960#action_12850960 ] 

Hontvari Jozsef commented on DBCP-329:
--------------------------------------

That is true. But I still feel the message is not right. The original exception which was hidden by the "Already closed" exception is relatively clear (assuming that you know the less then ideal MySQL behaviour regarding closing unused connections.) I guess what happens here is that when in a previous operation an exception was thrown, DBCP declares that the connection is closed. 
There is two cases, depending on how  DBCP works:
1) If it does try to connect the database on the close() operation, then it should throw the real exception. Like the hidden exception: jdbc4.CommunicationsException with message "Communications link failure". This is as informative as it could be (it is the responsibility of MySQL that it cannot be more informative).
2) If I am right, it does not connect the database on close(). It already knows that it was itself who declared that the connection was broken, and it already thrown an exception in a previous operation. We could very well say that DBCP was the one who "closed" the broken connection. In this case it should not throw another exception. I think that is in line with the intent of the Java specification, and DBCP has all necessasary informations which allows this behaviour.

If we look at from another viewpoint I think this usage pattern should work (and it worked before):
void fn() throws SQLException
{
  Connection connection = ....
  try {
    connection.doSomething();
  } finally {
    connection.close();
  }
}
Currently this throws the misleading "Already closed." exception instead of the more informative jdbc4.CommunicationsException.

> SQLException: Already closed.
> -----------------------------
>
>                 Key: DBCP-329
>                 URL: https://issues.apache.org/jira/browse/DBCP-329
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: MySQL
>            Reporter: Hontvari Jozsef
>
> After upgrading to 1.4 I see such exceptions logged:
> java.sql.SQLException: Already closed.
> 	at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114)
> 	at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
> 	...
> This should never happen. According to the Connection.close() javadoc: 
> "Calling the method close on a Connection object that is already closed is a no-op."
>  
> Moreover, I am pretty sure that our code does not close the connection twice. But because the close() is called in a finally block, it is possible that this exception hides another exception. Unfortunately I cannot reproduce it, even though it occurs regularly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.