Dear MySQL Users,

MySQL Connector/J 5.1.41, a maintenance release of the production 5.1
branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

Version 5.1.41 is suitable for use with many MySQL server versions,
including 4.1, 5.0, 5.1, 5.4 and 5.5.

MySQL Connector Java is available in source and binary form from the
Connector/J download pages at
http://dev.mysql.com/downloads/connector/j/5.1.html
and mirror sites as well as Maven-2 repositories.

MySQL Connector Java (Commercial) is already 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.41 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-41.html

Changes in MySQL Connector/J 5.1.41 (2017-02-28)

Version 5.1.41 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.

Bugs Fixed

* Connections failed with MySQLSyntaxErrorException:
Unknown character set when
connectionCollation=ISO-8859-13. This was due to a wrong
logic in Connector/J’s internal charset mapping, which
has now been fixed. (Bug #25504578)

* When loading classes through some external class loaders,
com.mysql.jdbc.Util threw an NoClassDefFoundError. This
was caused by Class.getPackage() returning null when some
external class loaders were used. This fix replaces those
calls of Class.getPackage() with calls of the new method
Class.getName(), which return package names that are
extracted from the fully-qualified class names. (Bug
#25048543, Bug #83052)

* In the manifest for the Connector/J JAR file, the
Import-Package directive specified version numbers for
the javax.net.ssl package. The specification was
unnecessary, and it caused the configuration of an SSL
connection to a MySQL server to fail in an OSGi
environment. The version requirement has now been
removed. (Bug #24942672, Bug #82826)

* In a Fabric setup, when multiple threads required to have
hashes computed, an ArrayIndexOutOfBoundsException might
be thrown from inside HashShardMapping. This fix prevents
the issue by having
HashShardMapping.getShardIndexForKey() synchronized. (Bug
#24289730, Bug #82203)

* When the configuration property cacheResultSetMetadata
was set to true, a ping query using a PreparedStatement
failed with a NullPointerException. This fix moves the
ping query to an earlier stage of the statement
execution, which prevents the exception. (Bug #23535001,
Bug #81706)

* The setFabricShardTable() method failed to parse
qualified table names (in the format of
database_name.table_name), which causes SQLExceptions to
be thrown. (Bug #23264511, Bug #81108)

* A race condition occurred when a call of
Connection.setNetworkTimeout() was followed closely by a
call of Connection.close(), and a NullPointerException
might result if the connection was closed before the
executor supplied to setNetworkTimeout() was able to set
the timeout, as the executor would run into a null
mysqlConnection object. This fix removed the race
condition. (Bug #21181249, Bug #75615)

* With the connection properties
cacheServerConfiguration=true and
elideSetAutoCommits=true, any new connection to the
server obtained after the first connection was
established had the variable autoCommit equaled false,
even if the value of the variable was true on the server.
That was because the value of autoCommit was not properly
initialized when a new connection was established, and
this fix corrects that.
Also, since release 5.1.41, the functionality of the
property elideSetAutoCommits has been disabled due to
Bug# 66884. Any value given for the property is now
ignored by Connector/J. (Bug #17756825, Bug #70785)

* When using Tomcat and a web application that utilized
Connector/J was down, Tomcat was unable to stop the
AbandonedConnectionCleanupThread started internally by
Connector/J, leading to multiple instances of the thread
when the web application was restarted; or, Tomcat was
able to stop the thread but unable to restart it on
reload of the web application. Different combinations of
Tomcat’s default settings, usage of Tomcat’s
ServletContextListener feature, and locations of the
Connector/J jar could result in the undesired behaviors,
as well as warning messages in the Tomcat error log
saying it was unable to stop the thread and a memory leak
was likely.
The implementation of AbandonedConnectionCleanupThread
has now been improved, so that there are now four ways
for developers to deal with the situation:

+ When the default Tomcat configuration is used and
the Connector/J jar is put into a local library
directory, the new built-in application detector in
Connector/J now detects the stopping of the web
application within 5 seconds and kills
AbandonedConnectionCleanupThread. Any unnecessary
warnings about the thread being unstoppable are also
avoided. If the Connector/J jar is put into a global
library directory, the thread is left running until
the JVM is unloaded.

+ When Tomcat’s context is configured with the
attribute clearReferencesStopThreads=”true”, Tomcat
is going to stop all spawned threads when the
application stops unless Connector/J is being shared
with other web applications, in which case
Connector/J is now protected against an
inappropriate stop by Tomcat; the warning about the
non-stoppable thread is still issued into Tomcat’s
error log.

+ When a ServletContextListener is implemented within
each web application that calls
AbandonedConnectionCleanupThread.checkedShutdown()
on context destruction, Connector/J now, again,
skips this operation if the driver is potentially
shared with other applications. No warning about the
thread being unstoppable is issued to Tomcat’s error
log in this case.

+ When
AbandonedConnectionCleanupThread.uncheckedShutdown()
is called, the AbandonedConnectionCleanupThread is
closed even if Connector/J is shared with other
applications. However, it may not be possible to
restart the thread afterwards.
(Bug #17035755, Bug #69526)
References: See also: Bug #14570236, Bug #16443387.

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla