Bug #67318 SQLException thrown on already closed ResultSet
Submitted: 22 Oct 2012 6:11 Modified: 10 Mar 2014 20:27
Reporter: ANDREY Andrey Radionov Email Updates:
Status: Closed Impact on me:
Category:Connector / J Severity:S5 (Performance)
Version:5.1.21 OS:Any
Assigned to: Alexander Soklakov CPU Architecture:Any
Tags: close, ResultSet, SqlException

[22 Oct 2012 6:11] ANDREY Andrey Radionov
Calling ResultSet.close on already closed ResultSet cause SQLException, which silently discarded. There is two issues with that:

1) This heavily affects performance.
2) Violates ResultSet API: "Calling the method close on a ResultSet object that is already closed is a no-op." (http://docs.oracle.com/javase/6/docs/api/java/sql/ResultSet.html#close%28%29)

Here is problem code in com.mysql.jdbc.ResultSetImpl:

		try {
			locallyScopedConn = checkClosed();
		} catch (SQLException sqlEx) {
			return; // already closed

This issue happens in normal-close scenario:
1) close ResultSet
2) close PreparedStatement
3) close Connection (in case of pooling)

Closing PreparedStatement force closing of its ResultSets. But ResultSet was closed in step1, so this generates SQLException in PreparedStatement.close.

How to repeat:
		Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test", "root", "1");
		PreparedStatement stmt = conn.prepareStatement("select 1 from dual");
		ResultSet rs = stmt.executeQuery();
		stmt.close(); // here SQLException will be generated and silently discarded
[3 Dec 2012 21:59] Andrej Golovnin
Patch to fix this issue.

Attachment: ResultSetImpl.patch (application/octet-stream, text), 658 bytes.

[3 Dec 2012 22:01] Andrej Golovnin
Andrey is right. We see also this problem. Using an exception to control the flow of the code is not so good idea IMHO.
[21 Dec 2012 8:03] Alexander Soklakov
Hi Andreys,

Thank you for the report.

Verified as described.
[31 Oct 2013 9:52] Raimar Falke
Another problem with this change is that the exception is always logged. This is noise in the logfile.

Please fix this behavior since any versions >= 5.1.21 are unusable for us.
[6 Feb 2014 13:27] Alexander Soklakov
Bug#17811638 marked as duplicate of this one.
[6 Feb 2014 13:29] Alexander Soklakov
Bug#70882 marked as duplicate of this one
[7 Mar 2014 17:08] Filipe Silva
Bug#71966 marked as duplicate of this one.
[7 Mar 2014 22:41] Diwaker Gupta
This bug is almost 1.5 yrs old. Given that multiple people have provided patches and considering the _significant_ performance impact this has, and especially considering that users are more likely to hit this with Java 7's try-with-resource, I'm apalled that this hasn't been fixed yet.

Can somoone comment on what the blocker(s) are for this to be accepted?
[10 Mar 2014 20:27] Daniel So
Added the following entry into the Connector/J 5.1.30 changelog:

"Calling ResultSet.close() on an already closed ResultSet caused an SQLException. While the exception was silently discarded, it did result in performance issues. This fix makes Connector/J comply with the Java specification that when a ResultSet object is already closed, application of the close method on it should be a no-op."
[19 Mar 2014 20:00] Diwaker Gupta
Thanks, can't wait for this update! Any ETA for the 5.1.30 release?
[20 Mar 2014 5:41] Alexander Soklakov
Hi Diwaker,

The date isn't defined yet. You could approximate taking into account that we try to do maintenance releases every 2-3 months.
[20 Mar 2014 16:03] Diwaker Gupta
Thanks, Alexander. The last release (5.1.29) was in February although 5.1.27 and 5.1.28 were released within a month of each other. So I'm guessing we should expect an April/May release?