Logic in implementations of LoadBalancingConnectionProxy and LoadBalanceStrategy behaved differently as to which SQLExceptions trigger failover to a new host. The former looked at the first two characters of the SQLState:

if (sqlState.startsWith("08"))
...

The latter used a different test:

if (sqlEx instanceof CommunicationsException
  || "08S01".equals(sqlEx.getSQLState())) {
...

This meant it was possible for a new Connection object to throw an Exception when the first selected host was unavailable. This happened because MySqlIO.createNewIO() could throw an SQLException with a SQLState of “08001”, which did not trigger the “try another host” logic in the LoadBalanceStrategy implementations, so an Exception was thrown after having only attempted connecting to a single host. (Bug#52231)

In the file DatabaseMetadata.java, the function private void getCallStmtParameterTypes failed if the parameter was defined over more than one line by using the '\n' character. (Bug#52167)

The catalog parameter, PARAM_CAT, was not correctly processed when calling for metadata with getMetaData() on stored procedures. This was because PARAM_CAT was hardcoded in the code to NULL. In the case where nullcatalogmeanscurrent was true, which is its default value, a crash did not occur, but the meta data returned was for the stored procedures from the catalog currently attached to. If, however, nullcatalogmeanscurrent was set to false then a crash resulted.

Connector/J has been changed so that when NULL is passed as PARAM_CAT it will not crash when nullcatalogmeanscurrent is false, but rather iterate all catalogs in search of stored procedures. This means that PARAM_CAT is no longer hardcoded to NULL (see Bug#51904). (Bug#51912)

A load balanced Connection object with multiple open underlying physical connections rebalanced on commit(), rollback(), or on a communication exception, without validating the existing connection. This caused a problem when there was no pinging of the physical connections, using queries starting with “/* ping */”, to ensure they remained alive. This meant that calls to Connection.commit() could throw a SQLException. This did not occur when the transaction was actually committed; it occurred when the new connection was chosen and the driver attempted to set the auto-commit or transaction isolation state on the newly chosen physical connection. (Bug#51783)

The rollback() method could fail to rethrow a SQLException if the server became unavailable during a rollback. The errant code only rethrew when ignoreNonTxTables was true and the exception did not have the error code 1196, SQLError.ER_WARNING_NOT_COMPLETE_ROLLBACK. (Bug#51776)

When a StatementInterceptor was used and an alternate ResultSet was returned from preProcess(), the original statement was still executed. (Bug#51666)

Objects created by ConnectionImpl, such as prepared statements, hold a reference to the ConnectionImpl that created them. However, when the load balancer picked a new connection, it did not update the reference contained in, for example, the PreparedStatement. This resulted in inserts and updates being directed to invalid connections, while commits were directed to the new connection. This resulted in silent data loss. (Bug#51643)

jdbc:mysql:loadbalance:// would connect to the same host, even though loadBalanceStrategy was set to a value of random, and multiple hosts were specified. (Bug#51266)