Version 5.1.40 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.
A very old workaround for Bug#36326 (fixed in release 5.1.32) has been removed, so Connector/J can now use local transaction states when the MySQL server has query cache enabled. (Bug #19974685)
Added support for the error codes of two MySQL server errors,
ER_XA_RBTIMEOUT
andER_XA_RBDEADLOCK
. (Bug #13702433, Bug #64188)
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)Continuing to use a Fabric connection after one of the slaves was removed might result in a
ConcurrentModificationException
. This happened because the list of slave hosts managed by Connector/J was being traversed and modified at the same time as the replication topology was changed. This patch fixes the issue by having Connector/J use a slave host list that is safe to be modified. (Bug #23738636)When the connection property
useCursorFetch
was “true” and updatable result sets were used,executeQuery()
failed for JSON data with anSQLException: Unknown type
. It was because the data decoding routine for updatable JSON data was missing from Connector/J, and it has now been implemented. (Bug #23197238)The
FabricMySQLConnectionProxy
methodnativeSQL()
always returnednull
. The method is now properly implemented. (Bug #23103408, Bug #81072)-
In a Fabric setup,
getMetaData().supportsMixedCaseIdentifiers()
always returned “true,” even iflower_case_table_names
was set to “1” on the servers. This was becauseFabricMySQLConnectionProxy.lowerCaseTableNames()
was not implemented properly. With this fix, the function now returns the proper value for the current active connection, so thatgetMetaData().supportsMixedCaseIdentifiers()
also returns the correct value.Users are reminded that in a Fabric setup,
lower_case_table_names
, as well as all other settings, should be configured the same way for all servers in the Fabric server group. (Bug #23103406, Bug #81056) -
A memory leakage occurred when the connection properties
cachePrepStmts
anduseServerPrepStmts
were both set to betrue
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 working with MySQL Fabric, Connector/J hung when the Fabric node was down. With this fix, when the Fabric node is down, all active connections continue to work based on the cached information on the server group and the sharding setup, although no new connections can be established. (Bug #22750465)
When Connector/J retrieved the value of a
BIT
column as an integer using, for example,getInt()
orgetLong()
, it returned a wrong value if the BIT value happened to be equivalent to the decimal value of some ASCII digit. This was because Connector/J attempted to parse the value as a string-encoded integer; thus, for example, the BIT value “110001” (decimal 49 in binary) was interpreted as the string “1” (whose ASCII value in decimal is 49), so the numerical value of “1” was returned. This fix corrected the parsing behavior of Connector/J onBIT
values, so they are always interpreted as binary coded. (Bug #21938551, Bug #78685)Connector/J could not parse the host name and port number from connection URLS staring with the word “address,” resulting in an
UnknownHostException
. This was because the URLs were being interpreted incorrectly as using the alternate URL format, which starts with “address=....” This patch fixes the parser for proper interpretation of the URL in the situation. (Bug #21389278, Bug #77649)When the connection property
useLocalTransactionState
was set to “true” andautocommit
was set to “false” on the server, if any exception was thrown, any further calls forrollback()
orcommit()
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, anSQLException
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)