Bug #26022 Invalid exception thrown by getTransactionIsolation()

• Submitted: 1 Feb 2007 17:27
• Modified: 1 Feb 2007 21:09
• Reporter: Guillaume Smet
• Status: Not a Bug
• Category: Connector / J
• Severity: S2 (Serious)
• Version: 5.0.4
• OS: Linux (Linux)
• CPU Architecture: Any

[1 Feb 2007 17:27] Guillaume Smet

Description:
I'm currently working on Sequoia, an open source database clustering solution written in Java.
One of our users had a problem because we are waiting for a SQLException (per the JDBC specification) and the MySQL JDBC driver throws a java.net.ConnectException which is not catched by Sequoia.

The problem is that getTransactionLevel() can throw exceptions which are not SQLException as they should be per spec.

This is a serious problem because it prevents Sequoia to requeue the query for execution in the recovery log and so it can break the replication.

You can find a description of the problem in Sequoia here: https://forge.continuent.org/jira/browse/SEQUOIA-910 .

--
Guillaume Smet
Open Wide

How to repeat:
- Open a connection to a MySQL Server with the JDBC driver
- Shutdown the server
- Then call getTransactionLevel() on this connection, it's going to throw a java.net.ConnectException

Suggested fix:
The code in Connection.getTransactionIsolation() looks like:
try {
    code
    rs = stmt.executeQuery(query);
    code
    if no valid resultset throws a SQLException
}
finally {
    code
}
So if the MySQL server is dead, the exception is not catched to wrap it into a SQLException as it should be the case.
I suggest to add a catch block to wrap the exception into a SQLException using SQLError.createSQLException if it's not already a SQLException.

[1 Feb 2007 18:19] Mark Matthews

I fail to see how Connection.getTransactionIsolation() can throw any of the exceptions from the java.net package, they're all checked exceptions.

The driver wraps checked exceptions from network faults into SQLExceptions already, are you sure you're _really_ seeing a network exception thrown from the driver?

If I test what you're doing, I get this:

com.mysql.jdbc.CommunicationsException (which is a subclass of SQLException)
Communications link failure due to underlying exception: 

** BEGIN NESTED EXCEPTION ** 

java.io.EOFException

STACKTRACE:

java.io.EOFException
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1908)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2299)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2798)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1568)
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1660)
	at com.mysql.jdbc.Connection.execSQL(Connection.java:3214)
	at com.mysql.jdbc.Connection.execSQL(Connection.java:3143)
	at com.mysql.jdbc.Statement.executeQuery(Statement.java:1179)
	at com.mysql.jdbc.Connection.getTransactionIsolation(Connection.java:3775)
	at Foo.main(Foo.java:709)

** END NESTED EXCEPTION **

[1 Feb 2007 21:09] Guillaume Smet

Hi Mark,

Yes, you're right. The log provided by the user was incomplete. I reproduced the problem and the java.net.ConnectException is correctly nested in a SQLException.

Sorry for the noise and thanks for your help.