MySQL Connector/J 5.1 Release Notes
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 the
fullDebug.properties
file was misspelled as
gatherPerMetrics
. 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
, an
ArrayIndexOutOfBoundsException
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 the getShort()
,
getInt()
, and
getLong()
methods in the
StringUtils
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, unneeded
StringBuffers
are replaced by
StringBuiders
.
(Bug #18389973, Bug #72008)
When exception interceptors were used, the
init()
method was called twice for each
exception interceptor, once by
Util.loadExtensions()
and again by
ConnectionImpl.ExceptionInterceptorChain.init()
.
This fix eliminates the calls by
ExceptionInterceptorChain.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 new
StandardSSLSocketFactory
class, which
implements SocketFactory
and wraps the
initial SocketFactory.afterHandshake()
method. MysqlIO.socketFactory
was replaced
after the socket transformation, so that
afterHandshake()
is performed on the old
factory but returns the new socket.
(Bug #18260918, Bug #71753)
When rewriteBatchedStatements=true
and
useAffectedRows=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
returns Statement.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 because
ProfilerEventHandlerFactory
kept a map in
which dead connections kept on accumulating. This fix refactors
the ProfilerEventHandlerFactory
and
eliminates that map.
(Bug #16737192, Bug #55680)
When useCursorFetch
was set to
true
, 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 of
Connection.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 subsequent close()
calls on cached
statements that have already been closed.
(Bug #16004987, Bug #66947)