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.
Connections failed with
MySQLSyntaxErrorException: Unknown character setwhen
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,
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
Import-Packagedirective specified version numbers for the
javax.net.sslpackage. 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
ArrayIndexOutOfBoundsExceptionmight be thrown from inside
HashShardMapping. This fix prevents the issue by having
HashShardMapping.getShardIndexForKey()synchronized. (Bug #24289730, Bug #82203)
When the configuration property
cacheResultSetMetadatawas set to
true, a ping query using a
PreparedStatementfailed 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)
setFabricShardTable()method failed to parse qualified table names (in the format of
table_name), which causes
SQLExceptionsto 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
NullPointerExceptionmight 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
mysqlConnectionobject. This fix removed the race condition. (Bug #21181249, Bug #75615)
With the connection properties
elideSetAutoCommits=true, any new connection to the server obtained after the first connection was established had the variable
false, even if the value of the variable was
trueon the server. That was because the value of
autoCommitwas 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
elideSetAutoCommitshas 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
AbandonedConnectionCleanupThreadstarted 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
ServletContextListenerfeature, 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
AbandonedConnectionCleanupThreadhas 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.
ServletContextListeneris 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.
AbandonedConnectionCleanupThread.uncheckedShutdown()is called, the
AbandonedConnectionCleanupThreadis 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.