In the class com.mysql.jdbc.jdbc2.optional.SuspendableXAConnection, which is used when pinGlobalTxToPhysicalConnection=true, there is a static map (XIDS_TO_PHYSICAL_CONNECTIONS) that tracks the Xid with the XAConnection, however this map was not populated. The effect was that the SuspendableXAConnection was never pinned to the real XA connection. Instead it created new connections on calls to start, end, resume, and prepare. (Bug#46925)

When using the ON DUPLICATE KEY UPDATE functionality together with the rewriteBatchedStatements option set to true, an exception was generated when trying to execute the prepared statement:

INSERT INTO config_table (modified,id_) VALUES (?,?) ON DUPLICATE KEY UPDATE modified=?

The exception generated was:

java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is
2).
	at com.sag.etl.job.processors.JdbcInsertProcessor.flush(JdbcInsertProcessor.java:135)
......
Caused by: java.sql.SQLException: Parameter index out of range (3 > number of parameters,
which is 2).
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926)
	at com.mysql.jdbc.PreparedStatement.checkBounds(PreparedStatement.java:3657)
	at com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:3641)
	at
com.mysql.jdbc.PreparedStatement.setBytesNoEscapeNoQuotes(PreparedStatement.java:3391)
	at
com.mysql.jdbc.PreparedStatement.setOneBatchedParameterSet(PreparedStatement.java:4203)
	at com.mysql.jdbc.PreparedStatement.executeBatchedInserts(PreparedStatement.java:1759)
	at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1441)
	at com.sag.etl.job.processors.JdbcInsertProcessor.flush(JdbcInsertProcessor.java:131)
	... 16 more

(Bug#46788)

When Connector/J encountered an error condition that caused it to create a CommunicationsException, it tried to build a friendly error message that helped diagnose what was wrong. However, if there had been no network packets received from the server, the error message contained the following incorrect text:

The last packet successfully received from the server was 1,249,932,468,916 milliseconds
ago.  The last packet sent successfully to the server was 0 milliseconds ago.

(Bug#46637)

The getSuperTypes method returned a result set with incorrect names for the first two columns. The name of the first column in the result set was expected to be TYPE_CAT and that of the second column TYPE_SCHEM. The method however returned the names as TABLE_CAT and TABLE_SCHEM for first and second column respectively. (Bug#44508)

SQLException for data truncation error gave the error code as 0 instead of 1265. (Bug#44324)

Calling ResultSet.deleteRow() on a table with a primary key of type BINARY(8) silently failed to delete the row, but only in some repeatable cases. The generated DELETE statement generated corrupted part of the primary key data. Specifically, one of the bytes was changed from 0x90 to 0x9D, although the corruption appeared to be different depending on whether the application was run on Windows or Linux. (Bug#43759)

Accessing result set columns by name after the result set had been closed resulted in a NullPointerException instead of a SQLException. (Bug#41484)

QueryTimeout did not work for batch statements waiting on a locked table.

When a batch statement was issued to the server and was forced to wait because of a locked table, Connector/J only terminated the first statement in the batch when the timeout was exceeded, leaving the rest hanging. (Bug#34555)

The parseURL method in class com.mysql.jdbc.Driver did not work as expected. When given a URL such as “jdbc:mysql://www.mysql.com:12345/my_database” to parse, the property PORT_PROPERTY_KEY was found to be null and the HOST_PROPERTY_KEY property was found to be “www.mysql.com:12345”.

(Bug#32216)

Attempting to delete rows using ResultSet.deleteRow() did not delete rows correctly. (Bug#27431)

The setDate method silently ignored the Calendar parameter. The code was implemented as follows:

public void setDate(int parameterIndex, java.sql.Date x, Calendar cal) throws SQLException {
   setDate(parameterIndex, x);
}        
      

From reviewing the code it was apparent that the Calendar parameter cal was ignored. (Bug#23584)