MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Hery Ramilison Date:May 9 2016 8:26pm
Subject:MySQL Connector/J 5.1.39 has been released
View as plain text  
Hello all,

MySQL Connector Java 5.1.39, a maintenance release of the production 5.1
branch, has been released. Connector/J is a Type-IV pure-Java JDBC driver
for MySQL, supporting the JDBC 4.2 API.  It is suitable for use with MySQL
server versions 5.5, 5.6, and 5.7.

MySQL Connector Java is available in source and binary form from the
Connector/J download page at

MySQL Connector Java (Commercial) is available for download on the My
Oracle Support (MOS) website. This release will be available on
eDelivery (OSDC) in next month's upload cycle.

As always, we recommend that you check the "CHANGES" file in the
download archive to be aware of changes in behavior that might affect
your application.

MySQL Connector/J 5.1.39 includes the following general bug fixes and
improvements, also available in more detail on :

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

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 Driver/Datasource
     Class Names, URL Syntax and Configuration Properties for
     reference-configuration-properties.html) for details.
     (Bug #22678872)
     References: See also: Bug #22848249.

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

   * 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

   * 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)


Reporting Bugs
We welcome and appreciate your feedback and bug reports:

On Behalf of the MySQL/ORACLE RE Team
Hery Ramilison
MySQL Connector/J 5.1.39 has been releasedHery Ramilison9 May