MySQL Connector/J 6.0 Release Notes  /  Changes in MySQL Connector/J 6.0.5 (2016-10-19, Milestone 4)

Changes in MySQL Connector/J 6.0.5 (2016-10-19, Milestone 4)

Version 6.0.5 Milestone is the forth development release of the 6.0 branch of MySQL Connector/J, providing an insight into upcoming features. 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.

Functionality Added or Changed

  • Added support for the error codes of two MySQL server errors, ER_XA_RBTIMEOUT and ER_XA_RBDEADLOCK. (Bug #13702433, Bug #64188)

  • X DevAPI: Client-side failover for establishing an XSession is now supported. See Configuring Client-Side Failover when using the X Protocol for more details.

  • com.mysql.cj.core.MysqlType can now be used as java.sql.SQLType in JDBC methods.

  • X DevAPI: A new method, createTable(), has been added to the Schema interface. See MySQL Connector/J X DevAPI Reference for details.

  • X DevAPI: A new method, bindToDefaultShard(), has been added to the XSession interface. It creates a virtual NodeSession instance, which shares the connection to the router with the XSession that was used to create it. See MySQL Connector/J X DevAPI Reference for details.

  • X DevAPI: For any function that takes a value list of parameters for its argument, there is now more flexibility with how the parameters are to be specified: they can now be supplied either as a value list or a list of individual parameters.

  • The Extension interface has been removed. Extension classes now implement their own interfaces.

Bugs Fixed

  • Connecting to a MySQL server with an invalid connection URL resulted in a WrongArgumentException and a stack trace. With this fix, the connection failed in the situation with an SQLException and without a stack trace. (Bug #24613062, Bug #82896)

  • In certain cases, the exception interceptor was being triggered twice in the internal SQLException factory method. Also, if the exception interceptor returned an exception with the cause already initialized, the same factory method would fail to initialize the cause again, and the real cause for the exception remained uncaptured. (Bug #23743956)

  • getLength() returned -1 for fields of the LONGBLOBL, LONGTEXT, and GEOMETRY data types. This is due to the way these data types are handled by protocol buffers, and this fix makes the method return the right values. (Bug #22988922)

  • A memory leakage occurred when the connection properties cachePrepStmts and useServerPrepStmts were both set to be true and server-side prepared statements were set as non-poolable, which resulted in the prepared statement being not closable by the client, and the number of prepared statements then kept on increasing.

    When the memory leakage described above occurred, it did not make Connector/J fail, as Connector/J switched to using client-side prepared statements when the maximum number of prepared statements was reached. However, when rewriteBatchedStatements was also set to true, the switch to client-side prepared statements did not occur, and Connector/J threw the MySQLSyntaxErrorException (Can't create more than max_prepared_stmt_count statements) when the client wanted to create more prepared statements than allowed.

    This fix corrected the way prepared statements are handled in order to avoid both of the problems described above. (Bug #22954007, Bug #80615)

  • ResultSet.getString() sometimes returned garbled data for columns of the JSON data type. This was because JSON data was binary encoded by MySQL using the utf8mb4 character set, but decoded by Connector/J using the ISO-8859-1 character set. This patch fixes the decoding for JSON data. Thanks to Dong Song Ling for contributing to the fix. (Bug #22891845, Bug #80631)

  • When Connector/J retrieved the value of a BIT column as a string using, for example, getString(), it returned the wrong string if the BIT value happened to be equivalent to the decimal value of some ASCII character. This was because Connector/J treated the BIT value as a character code; thus, for example, the value 01100001 (decimal 97 in binary) was interpreted as the character a (whose ASCII value in decimal is 97), which was returned by the function. This fix corrects the parsing behavior of Connector/J on BIT values, so that a string representation of the number (97 in the last example) is returned by getString(). (Bug #21938551, Bug #78685)

  • When the connection property useLocalTransactionState was set to true and autocommit was set to false on the server, if any exception was thrown, any further calls for rollback() or commit() were not sent to the server. It was because when there was an exception while executing a query, Connector/J lost the information regarding the server's transaction state. This patch fixes this issue by preserving the previous transaction state for the current connection when any exception is thrown. (Bug #20212882, Bug #75209)

  • An invalid connection URL caused Connector/J to throw a NullPointerException. With this fix, an SQLException is thrown instead in the situation. (Bug #18759269, Bug #72632)

  • When a very large amount of compressed data is transmitted from the server to the client and under very special circumstances, a CommunicationsException might occur. It happened when a single compressed packet from the server was not big enough to provide an entire uncompressed packet to the client side. With this fix, Connector/J reads as many compressed packets as necessary to fill the size of the uncompressed packet that was being requested. Thanks to Ryosuke Yamazaki for contributing to the fix. (Bug #11756431, Bug #48346)