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
http://dev.mysql.com/downloads/connector/j/5.1.html
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
Connector/J
(http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-
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
#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
