You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Hontvari Jozsef (JIRA)" <ji...@apache.org> on 2010/03/28 22:17:27 UTC
[jira] Created: (DBCP-329) SQLException: Already closed.
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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Paul Benedict (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851240#action_12851240 ]
Paul Benedict commented on DBCP-329:
------------------------------------
Phil, you piqued my interest. Let's say a production database crashes during the day (my company is familiar with it!), which naturally kills all connections. The crash happened in-between the last good operation but before the close(). Do you intend an exception to propagate to the caller who is now finished with the database? Just seems like an unnecessary hassle. Any further thoughts?
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851360#action_12851360 ]
Phil Steitz commented on DBCP-329:
----------------------------------
James: good point, but the answer is "not exactly." The check on isClosed() that I mentioned above happens *before* the connection is returned to the pool (in the pool lifecycle, before passivate happens). What it comes down to is do we want to let the client know (via an exception) as soon as we detect the condition that one of the connections handled by the pool has been closed externally. The reasonable alternative behavior be to "silently" dispose of the connection wrapper and exit close normally. One reason to let the client know about this is that DBCP in this case is not fulfilling any of its normal "close" contract cleanup actions (rollbacks, etc.).
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Paul Benedict (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851386#action_12851386 ]
Paul Benedict commented on DBCP-329:
------------------------------------
My employer does high-transaction processing -- about 2 million real-time invocations a day -- and are also on a mainframe where they pay for processor usage. They prohibit a validation query since it would cost 2 million more SQL statements a day. In an emergency reboot, connections are left hanging and each one throws an exception until the pool is re-cleared. It would be nice to see an option where a stale connection (exception from isClose()?) refreshes the entire pool.
I agree with Phi. There's no right answer except what is right for you. I think we should support some configuration option where either (1) silent disposal (2) throw exception and (3) refresh the pool.
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "James Carman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851355#action_12851355 ]
James Carman commented on DBCP-329:
-----------------------------------
Wouldn't a lot of this be solved by using a validation query (and test-on-borrow)?
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Paul Benedict (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850940#action_12850940 ]
Paul Benedict commented on DBCP-329:
------------------------------------
{quote}
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."
{quote}
I grant you that, but you're reading the spec wrong. If you already called close() on the socket, then calling it again should do nothing. However, your situation is different: the other side of the socket closed the socket. Java has no way of knowing whether that occurred except by reading or writing the socket again and then failing. Google this subject and you will find the same answer.
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851356#action_12851356 ]
Phil Steitz commented on DBCP-329:
----------------------------------
Honestly, I am ambivalent on this. I can see the argument on both sides. The use case reported here is another good example of one in which the client would prefer silent disposal - close in a finally block after the badness has been encountered on use. On the other hand, I can see situations where the client really would like to know about these events.
What do you think, Paul? Other opinions?
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Hontvari Jozsef (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (DBCP-329) SQLException: Already closed.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz closed DBCP-329.
----------------------------
Resolution: Duplicate
Duplicates DBCP-193
> 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.
[jira] Issue Comment Edited: (DBCP-329) SQLException: Already
closed.
Posted by "Hontvari Jozsef (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850960#action_12850960 ]
Hontvari Jozsef edited comment on DBCP-329 at 3/29/10 4:17 PM:
---------------------------------------------------------------
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 necessary informations which allows this behavior.
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.
was (Author: hontvari):
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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Hontvari Jozsef (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851384#action_12851384 ]
Hontvari Jozsef commented on DBCP-329:
--------------------------------------
>If the driver returns false, something bad has happened, because DBCP thinks the connection is open and the driver is reporting that it is closed.
As I see two kind of bad thing could have happened:
1) There was an exception in a previous operation on the connection. DBCP know about this fact, as DBCP is part of the call chain. The client code also knows about that exception, moreover, that exception contains relevant information about the problem. There is no need to issue a secondary exception on close() which does not add information (or actually mislead).
2) The client code closed the underlying connection.
That may indicate a bug, but you have to work hard to make this bug, you need to access the underlying connection and then close it. It is also possible that is is not a bug: the client code itself closes the underlying connection after using it because for example some problem happened. In this case it is a feature if DBCP does check isClosed and acknowledges it by not throwing an exception.
3) (A third possibility could be that the client borrowed the connection and does not use it. But in this case the client is not interested in the state of the is connection at all)
Here is the template code which should be used if the current behavior remains:
Connection connection = ...
try {
connection.doSomething();
} finally {
try {
connection.close();
} catch (SQLException e) {
logger.warn("Close was not successful. This is likely caused by another exception, look at later log entries.", e);
}
}
> 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.
[jira] Commented: (DBCP-329) SQLException: Already closed.
Posted by "Hontvari Jozsef (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850936#action_12850936 ]
Hontvari Jozsef commented on DBCP-329:
--------------------------------------
I inserted some additional logging to debug this case, and indeed it hides another exception:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 8,064,672 milliseconds ago. The last packet sent successfully to the server was 8,064,672 milliseconds ago.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1122)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3317)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1941)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2114)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2696)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2105)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2264)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
...
Caused by: java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3298)
... 34 common frames omitted
So the latter exception is not related to DBCP, only the "already closed" in my original report.
> 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.
[jira] Closed: (DBCP-329) SQLException: Already closed.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz closed DBCP-329.
----------------------------
Resolution: Fixed
When you invoke the close method on a connection managed by DBCP, you are asking DBCP to return it to the pool. Before returning a connection to the pool, DBCP issues the JDBC driver call, _conn.isClosed() on the underlying physical connection to make sure that it is still open. If the driver returns false, something bad has happened, because DBCP thinks the connection is open and the driver is reporting that it is closed. In this case, the exception that you are observing is thrown. Your own exception handler is masking the exception that your code encountered trying to use the connection that had been closed on the server side.
See http://markmail.org/message/c2gx2xuzum4pv743 for discussion of a similar issue. If anyone feels that DBCP should be modified to silently dispose of bad connections returned to the pool, please reopen DBCP-193.
> 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.
[jira] Reopened: (DBCP-329) SQLException: Already closed.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz reopened DBCP-329:
------------------------------
> 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.