random: The driver will pick a random host
for each request. This tends to work better than round-robin, as
the randomness will somewhat account for spreading loads where
requests vary in response time, while round-robin can sometimes
lead to overloaded nodes if there are variations in response
times across the workload.
Driver will now use
INSERT INTO ... VALUES
(DEFAULT)form of statement for updatable result sets
ResultSet.insertRow(), rather than
pre-populating the insert row with values from
COLUMNS on the server for every result set). If an
application requires access to the default values before
insertRow() has been called, the JDBC URL
should be configured with
populateInsertRowWithDefaultValues set to
This fix specifically targets performance issues with ColdFusion and the fact that it seems to ask for updatable result sets no matter what the application does with them.
understands URLs of the format
jdbc:mysql:loadbalance:// which will create a
ReplicationConnection (exactly like when using
[NonRegistering]ReplicationDriver) and an
experimental load-balanced connection designed for use with SQL
nodes in a MySQL Cluster/NDB environment, respectively.
In an effort to simplify things, we're working on deprecating
multiple drivers, and instead specifying different core behavior
based upon JDBC URL prefixes, so watch for
eventually disappear, to be replaced with
com.mysql.jdbc[NonRegistering]Driver with the
new URL prefix.
More intelligent initial packet sizes for the "shared" packets are used (512 bytes, rather than 16K), and initial packets used during handshake are now sized appropriately as to not require reallocation.
Fixed issue where a failed-over connection would let an
that call should be ignored until the connection is reconnected
to a writable master unless
had been set to
bestResponseTime: The driver will route the
request to the host that had the best response time for the
Added an experimental load-balanced connection designed for use
with SQL nodes in a MySQL Cluster/NDB environment (This is not
for master-slave replication. For that, we suggest you look at
If the JDBC URL starts with
the driver will create an implementation of
java.sql.Connection that load balances
requests across a series of MySQL JDBC connections to the given
hosts, where the balancing takes place after transaction commit.
Therefore, for this to work (at all), you must use transactions, even if only reading data.
Physical connections to the given hosts will not be created until needed.
The driver will invalidate connections that it detects have had communication errors when processing a request. A new connection to the problematic host will be attempted the next time it is selected by the load balancing algorithm.
There are two choices for load balancing algorithms, which may
be specified by the
URL configuration property:
random: The driver will pick a random
host for each request. This tends to work better than
round-robin, as the randomness will somewhat account for
spreading loads where requests vary in response time, while
round-robin can sometimes lead to overloaded nodes if there
are variations in response times across the workload.
bestResponseTime: The driver will route
the request to the host that had the best response time for
the previous transaction.
useLocalSessionState is set to
true and connected to a MySQL-5.0 or later
server, the JDBC driver will now determine whether an actual
statement needs to be sent to the database when
Connection.rollback() is called.
This is especially helpful for high-load situations with
connection pools that always call
Connection.rollback() on connection
check-in/check-out because it avoids a round-trip to the server.
Give better error message when "streaming" result sets, and the
connection gets clobbered because of exceeding
net_write_timeout on the
New configuration property,
When enabled, query timeouts set with
Statement.setQueryTimeout() use a shared
java.util.Timer instance for scheduling. Even
if the timeout doesn't expire before the query is processed,
there will be memory used by the
for the given timeout which won't be reclaimed until the time
the timeout would have expired if it hadn't been cancelled by
the driver. High-load environments might want to consider
disabling this functionality. (this configuration property is
part of the
Added configuration property
useDynamicCharsetInfo. If set to
false (the default), the driver will use a
per-connection cache of character set information queried from
the server when necessary, or when set to
true, use a built-in static mapping that is
more efficient, but isn't aware of custom character sets or
character sets implemented after the release of the JDBC driver.
This only affects the
configuration property and the
Added configuration property
padCharsWithSpace (defaults to
false). If set to
and a result set column has the
CHAR type and the value does not
fill the amount of characters specified in the DDL for the
column, the driver will pad the remaining characters with space
(for ANSI compliance).
More useful error messages are generated when the driver thinks a result set is not updatable. (Thanks to Ashley Martens for the patch). (Bug #28085)
SHOW VARIABLES LIKE" which is very
inefficient on MySQL-5.0+ servers.
Fixed issue where calling
on a prepared statement after calling
execute() didn't always return the generated
executeUpdate() worked fine however).
CALL /* ... */
As a side effect of this fix, you can now use
# comments when preparing
statements using client-side prepared statement emulation.
If the comments happen to contain parameter markers
?), they will be treated as belonging to the
comment (that is, not recognized) rather than being a parameter
of the statement.
The statement when sent to the server will contain the
comments as-is, they're not stripped during the process of
ResultSet.get*() with a column index < 1
returns misleading error message.
ResultSet.get*() with a column index
less than 1 returns a misleading error message.
Comments in DDL of stored procedures/functions confuse procedure parser, and thus metadata about them can not be created, leading to inability to retrieve said metadata, or execute procedures that have certain comments in them. (Bug #26959)
Fast date/time parsing doesn't take into account
00:00:00 as a legal value.
PreparedStatement is not closed in
When the configuration property
useCursorFetch was set to
true, sometimes server would return new, more
exact metadata during the execution of the server-side prepared
statement that enables this functionality, which the driver
ignored (using the original metadata returned during
prepare()), causing corrupt reading of data
due to type mismatch when the actual rows were returned.
Whitespace surrounding storage/size specifiers in stored
procedure parameters declaration causes
NumberFormatException to be thrown when
calling stored procedure on JDK-1.5 or newer, as the Number
classes in JDK-1.5+ are whitespace intolerant.
Client options not sent correctly when using SSL, leading to stored procedures not being able to return results. Thanks to Don Cohen for the bug report, testcase and patch. (Bug #25545)
Statement.setMaxRows() is not effective on
result sets materialized from cursors.
BIT(> 1) is returned as
ResultSet.getObject() rather than