Web lists-archives.com

MySQL Connector/J 5.1.39 has been released

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
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-39.html :

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)

Online: http://dev.mysql.com/doc/connector-j/5.1/en/

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

On Behalf of the MySQL/ORACLE RE Team
Hery Ramilison

MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql