Documentation Home
MySQL Connector/J 5.1 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 0.6Mb
PDF (A4) - 0.6Mb


MySQL Connector/J 5.1 Release Notes  /  Changes in MySQL Connector/J 5.1  /  Changes in MySQL Connector/J 5.1.45 (2017-11-30)

Changes in MySQL Connector/J 5.1.45 (2017-11-30)

Version 5.1.45 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.

Functionality Added or Changed

  • Character set mappings have been added for the following collations:

    • utf8mb4_ja_0900_as_cs_ks

    • utf8mb4_0900_as_ci

    • utf8mb4_ru_0900_ai_ci

    • utf8mb4_ru_0900_as_cs

    (Bug #26724085)

Bugs Fixed

  • With the combination of the connection properties useServerPrepStmts=true, useInformationSchema=true, useCursorFetch=true, and defaultFetchSize=N, if a warning was returned for a query during connection initialization, a NullPointerException would result when Connector/J tried to get the warning. That was because the charsets were not yet initialized in the connection at the time. This fix corrects the problem by preventing cursors from being used when Connector/J fetches warnings from the server. (Bug #27131768)

  • When a communications exception was thrown by Connector/J after a socket timeout event, because the current transaction did not get rolled back automatically, if autoReconnect=true, the next statement execution by Connector/J might reuse the old server session and continued with the previous transaction. This might confuse the client application on the transaction status of the statements it was handling. This fix corrects the issue by forcibly closing the network resources after a communication or IO exception, causing the server to rollback the transaction. (Bug #27047676, Bug #88232)

  • Normally, when the socketTimeout option has been set and a socket timeout occurs on the client side, the server may continue working and returning query results. At the next query executed after the timeout, Connector/J first clears the socket input stream and then sends a ping request to the server.

    However, an error occurred if the autoReconnect option was set to true and, after reconnection, a new query was executed by Connector/J, and the results from the previous queries arrived before Connector/J sent its ping request to the server, in which case the old packages might be mistaken as results for the new query. This fix corrects the issue by forcibly closing the network resources after a communication or IO exception. The next statement execution recreates the IO stream if autoReconnect=true; otherwise, the connection stays closed. (Bug #27040063, Bug #88242)

  • High garbage collection pressure was observed when there were a lot of queries performed using server-side prepared statements. This patch reduces the pressure by optimizing the generation process of the cache keys for the prepared statements. Thanks to Johnathan Crawford for contributing the patch. (Bug #26939943, Bug #88021)

  • A number of regression tests for former bug fixes failed when they were run against MySQL Server 8.0.3, because binary logging has been enabled by default on the server. The tests have now been fixed. (Bug #26794652)

  • A number of regression tests for former bug fixes failed when they were run against MySQL Server 8.0.3 because of the name changes of some of the INFORMATION_SCHEMA tables on the server. The tests have now been fixed. (Bug #26794602)

  • When server-side prepared statements and cursor-based result sets were used, exceptions were thrown when applications made calls to get output parameters of INTEGER or BIGINT type from a result set. (Bug #26771560, Bug #87704)