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 set
whenconnectionCollation=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 anNoClassDefFoundError
. This was caused byClass.getPackage()
returning null when some external class loaders were used. This fix replaces those calls ofClass.getPackage()
with calls of the new methodClass.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, theImport-Package
directive specified version numbers for thejavax.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 insideHashShardMapping
. This fix prevents the issue by havingHashShardMapping.getShardIndexForKey()
synchronized. (Bug #24289730, Bug #82203)When the configuration property
cacheResultSetMetadata
was set totrue
, a ping query using aPreparedStatement
failed with aNullPointerException
. 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 ofdatabase_name
.table_name
), which causesSQLExceptions
to be thrown. (Bug #23264511, Bug #81108)A race condition occurred when a call of
Connection.setNetworkTimeout()
was followed closely by a call ofConnection.close()
, and aNullPointerException
might result if the connection was closed before the executor supplied tosetNetworkTimeout()
was able to set the timeout, as the executor would run into a nullmysqlConnection
object. This fix removed the race condition. (Bug #21181249, Bug #75615)-
With the connection properties
cacheServerConfiguration=true
andelideSetAutoCommits=true
, any new connection to the server obtained after the first connection was established had the variableautoCommit
equaledfalse
, even if the value of the variable wastrue
on the server. That was because the value ofautoCommit
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'sServletContextListener
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 callsAbandonedConnectionCleanupThread.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, theAbandonedConnectionCleanupThread
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.