Changes in MySQL Connector/J 5.1.31 (2014-06-07)

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.

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• Added support for sha256_password authentication with RSA encryption.

Bugs Fixed

• 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)