Version 5.1.31 is a maintenance release of the production 5.1 branch. It is suitable for use with many MySQL Server versions, including 4.1, 5.0, 5.1, 5.4, 5.5, and 5.6.
Added support for
sha256_password
authentication with RSA encryption.
The option name
gatherPerfMetrics
in thefullDebug.properties
file was misspelled asgatherPerMetrics
. That resulted in the performance metrics not being logged. The name has been corrected in both the file and the Connector/J manual. (Bug #18598665, Bug #72326)The MySQL Fabric driver did not properly propagate exceptions thrown during connection creation using JDBC 4. (Bug #18549472, Bug #72301)
In the method
MysqlIO.unpackBinaryResultSetRow
, an array was created unnecessarily to hold the null bit mask. With this fix, Connector/J avoids the creation of the array by making use of the data that is still variable in the original buffer object. (Bug #18403456, Bug #72023)In the method
PreparedStatement.ParseInfo
, a character array was created unnecessarily out of a string object. This fix removed the unnecessary instantiation of the array. (Bug #18403199, Bug #72006)When trying to get an integer from a column value that was not a number, instead of a
NumberFormatException
, anArrayIndexOutOfBoundsException
was thrown instead due to an off-by-one error. This fix corrects the stop condition for trimming spaces in the beginning of byte buffers in thegetShort()
,getInt()
, andgetLong()
methods in theStringUtils
class. (Bug #18402873, Bug #72000)The
StringUtils.getBytes
methods have been refactored to avoid unnecessary creations of string objects for encoding character arrays into bytes. Also, unneededStringBuffers
are replaced byStringBuiders
. (Bug #18389973, Bug #72008)When exception interceptors were used, the
init()
method was called twice for each exception interceptor, once byUtil.loadExtensions()
and again byConnectionImpl.ExceptionInterceptorChain.init()
. This fix eliminates the calls byExceptionInterceptorChain.init()
. (Bug #18318197, Bug #71850)After a non-SSL socket had been transformed into an SSL socket,
Connection
was still keeping its reference to the wrapped, non-SSL socket, failing to recognize that the type of connection had been changed. This fix creates a newStandardSSLSocketFactory
class, which implementsSocketFactory
and wraps the initialSocketFactory.afterHandshake()
method.MysqlIO.socketFactory
was replaced after the socket transformation, so thatafterHandshake()
is performed on the old factory but returns the new socket. (Bug #18260918, Bug #71753)When
rewriteBatchedStatements=true
anduseAffectedRows=true
were set,executeBatch()
returned the number of affected rows as given by the server, which was not a reliable value unless it was a “0”. That behavior was due to the fix for Bug#68562, which was implemented in Connector/J 5.1.27 (see the changelog for the release), and has been breaking a number of applications that use Connector/J. In this new fix, Connector/J returnsStatement.SUCCESS_NO_INFO
as a result for each statement in the batch as long as there are more than one batched statement and the returned value for the affected rows from the server is greater than “0”. Connector/J returns a “0” otherwise, which indicates that no rows have been affected. (Bug #18009254, Bug #61213)If
profileSQL
was enabled, a memory leak would occur after a connection was lost and continuous attempts were made to reconnect. It was becauseProfilerEventHandlerFactory
kept a map in which dead connections kept on accumulating. This fix refactors theProfilerEventHandlerFactory
and eliminates that map. (Bug #16737192, Bug #55680)When
useCursorFetch
was set totrue
, Connector/J would attempt to send XA commands as server prepared statements, which were unsupported, and the commands would have to be resent as plain statements. This fix stops Connector/J from sending XA commands as server prepared statements. (Bug #16708231, Bug #67803)When closing a server-prepared statement twice and
cachePrepStmts=true
, the second call closed the statement as expected. However, if a call ofConnection.prepareStatement()
was made again with exactly same SQL string, Connector/J obtained the closed statement from the cache and failed by throwing an exception. With this fix,ServerPreparedStatement.close()
detects and ignores subsequentclose()
calls on cached statements that have already been closed. (Bug #16004987, Bug #66947)