2.9 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 an error with 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.