Changes in MySQL Connector/J 5.1.39 (2016-05-09)

Version 5.1.39 is a maintenance release of the production 5.1 branch. It is suitable for use with MySQL Server versions 5.5, 5.6, and 5.7. It supports the Java Database Connectivity (JDBC) 4.2 API.

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• For MySQL server 5.7.5 and later, the EOF packet in the MySQL server/client protocol has been deprecated and replaced by the OK packet. The change is now supported by Connector/J. (Bug #23212347)

Bugs Fixed

• Connector/J hung, returned a NullPointerException, or returned an incorrect exception when using result sets with the properties TYPE_FORWARD_ONLY and CONCUR_UPDATABLE. It was due to an inaccurate check for the cursor for the result set. This fix makes sure Connector/J checks accurately on whether a cursor has been requested, both when executing a statement and fetching its results. (Bug #23201930)

• When using server-side prepared statements with profileSQL=true and useInformationSchema=true, an SQLException (“ ResultSet is from UPDATE. No Data”) occurred when the client tried to advance to the next row in the result set. This was due to a failure of an internal query for metadata, which is now prevented by this fix. (Bug #23188498)

• LoadBalanceConnectionGroupManager.removeHost() was not removing hosts as expected. This fix tries to ensure that host removals will be successful under different situations. (Bug #22848249)

  References: See also: Bug #22678872.

• For connections with useCursorFetch=true and fetch size set with defaultFetchSize or setFetchSize, if data from a TIME and a BLOB data column was selected together, corrupted value for the TIME data was returned. (Bug #22833410, Bug #80522)

• For a load-balanced connection, an ArrayIndexOutOfBoundsException was thrown when ConnectionGroupManager.removeHost() was called. It was due to an error in LoadBalancedConnectionProxy.removeHost(), which has now been fixed. (Bug #22730682)

• A Fabric connection threw a NullPointerException when all hosts have been removed from its host list, or when the internal load-balanced connection became null due to inconsistency of the replication connection. This fix adds to Connector/J the abilities to handle those situations. Also, a new connection property, loadBalanceHostRemovalGracePeriod, has been introduced, which sets the grace period for waiting to remove the currently active host from a load-balanced connection. See the entry for the new property in Configuration Properties for Connector/J for details. (Bug #22678872)

  References: See also: Bug #22848249.

• FabricMySQLDataSource.getConnection() threw a null pointer exception when a master failover took place. (Bug #22598938)

• The OSGi manifest file in the Connector/J JAR file did not expose the MySQL Fabric packages, so the Fabric-related classes could not be resolved even though they were present in the JAR file. (Bug #22385172)

• With some Tomcat web applications, when Connector/J connects to the server with useLegacyDatetimeCode=false without setting serverTimeZone, a NullPointerException was returned. This was because the timezone property file for Connector/J was loaded by the bootstrap class loader, which did not know the location of the property file and thus failed to load it. This fix avoids the problem by making Connector/J use the same class loader for both the property file and the Connector/J classes. (Bug #22353759, Bug #79343)

• When using JDBC 4.2 and with the connection property cachePrepStmts set to “true,” after a prepared statement had been cached, rerunning the SQL statement resulted in a pre-JDBC 4.2 PreparedStatement object being instantiated. This fix prevents the problem by having the PreparedStatement instantiated by a factory instead of a constructor method. (Bug #22352812, Bug #79598)

• At every connection, Connector/J got the sql_mode variable from the server and tried to parse it as a number; because sql_mode is not a number (except for very old versions of MySQL), an NumberFormatException was always thrown and then caught by the code. This fix refactored the code to avoid the unnecessary throwing and catching of the error. (Bug #21181466, Bug #77171)

• When inserting multiple timestamp values into a table with useLegacyDatetimeCode=false and useCursorFetch=true, after a null value had been inserted, further inserts could not change a timestamp's value. This fix makes sure the binding of the value is reset before a new insert takes place. (Bug #20685487, Bug #75956)

• The exception message in CallableStatement() for incorrect output parameter registration gave little detail and the wrong error code. (Bug #18068303, Bug #71131)

• Calling getTimestamp() on a timestamp column resulted in a java.sql.SQLException (“Cannot convert value ... to TIMESTAMP”). That was due to the missing metadata for each row in the ResultSet. This fix ensures that the metadata is no longer missing. (Bug #16738378, Bug #56479)

• On very fast servers with other third-party components accessing the data, a ConcurrentModificationException was sometimes thrown. This fix prevents the exception by adding a synchronization to ConnectionImpl.closeAllOpenStatements(), and by refactoring part of the code inside the method. (Bug #16736619, Bug #59462)