Version 5.1.39 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.
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)
Connector/J hung, returned a NullPointerException, or returned an incorrect exception when using result sets with the properties
TYPE_FORWARD_ONLY
andCONCUR_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
anduseInformationSchema=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 withdefaultFetchSize
orsetFetchSize
, if data from aTIME
and aBLOB
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 inLoadBalancedConnectionProxy.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 Configuration Properties for Connector/J 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 settingserverTimeZone
, 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.2PreparedStatement
object being instantiated. This fix prevents the problem by having thePreparedStatement
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
anduseCursorFetch=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 toConnectionImpl.closeAllOpenStatements()
, and by refactoring part of the code inside the method. (Bug #16736619, Bug #59462)