Quantcast
Channel: MySQL Forums - Announcements
Viewing all articles
Browse latest Browse all 1041

MySQL Connector/J 5.1.39 has been released (no replies)

$
0
0
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 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)

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

Reporting Bugs
---------------
We welcome and appreciate your feedback and bug reports:
http://bugs.mysql.com/

On Behalf of the MySQL/ORACLE RE Team
Hery Ramilison


Viewing all articles
Browse latest Browse all 1041

Latest Images

Trending Articles



Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>