MySQL Connector/J 5.1 Release Notes
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
and
ER_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 an
SQLException: 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
method
nativeSQL()
always returned
null
. The method is now properly implemented.
(Bug #23103408, Bug #81072)
In a Fabric setup,
getMetaData().supportsMixedCaseIdentifiers()
always returned “true,” even if
lower_case_table_names
was set to “1” on the servers. This was because
FabricMySQLConnectionProxy.lowerCaseTableNames()
was not implemented properly. With this fix, the function now
returns the proper value for the current active connection, so
that
getMetaData().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
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 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()
or getLong()
, 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 on
BIT
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” 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)