Functionality added or changed:
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
ReplicationConnection
or
lbpool
).
If the JDBC URL starts with
jdbc:mysql:loadbalance://host-1,host-2,...host-n
,
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 loadBalanceStrategy
JDBC
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.
bestResponseTime
— the driver will
route the request to the host that had the best response time
for the previous transaction.
Added configuration property
padCharsWithSpace
(defaults to
false
). If set to true
,
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).
When useLocalSessionState
is set to
true
and connected to a MySQL-5.0 or later
server, the JDBC driver will now determine whether an actual
commit
or rollback
statement needs to be sent to the database when
Connection.commit()
or
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.
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 padCharsWithSpace
configuration property and the
ResultSetMetaData.getColumnDisplayWidth()
method.
New configuration property,
enableQueryTimeouts
(default
true
).
When enabled, query timeouts set via
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 TimerTask
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 maxPerformance
configuration
bundle).
Give better error message when "streaming" result sets, and the
connection gets clobbered because of exceeding
net_write_timeout
on the
server.
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.
com.mysql.jdbc.[NonRegistering]Driver
now
understands URLs of the format
jdbc:mysql:replication://
and
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
[NonRegistering]ReplicationDriver
to
eventually disappear, to be replaced with
com.mysql.jdbc[NonRegistering]Driver
with the
new URL prefix.
Fixed issue where a failed-over connection would let an
application call setReadOnly(false)
, when
that call should be ignored until the connection is reconnected
to a writable master unless failoverReadOnly
had been set to false
.
Driver will now use INSERT INTO ... VALUES
(DEFAULT)
form of statement for updatable result sets
for ResultSet.insertRow()
, rather than
pre-populating the insert row with values from
DatabaseMetaData.getColumns()
(which results
in a SHOW FULL
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
true
.
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.
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.
Bugs fixed:
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)
Connection.getTransactionIsolation()
uses
"SHOW VARIABLES LIKE
" which is very
inefficient on MySQL-5.0+ servers.
(Bug#27655)
Fixed issue where calling getGeneratedKeys()
on a prepared statement after calling
execute()
didn't always return the generated
keys (executeUpdate()
worked fine however).
(Bug#27655)
CALL /* ... */
doesn't work.
As a side effect of this fix, you can now use some_proc
()/*
*/
and #
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
preparing the PreparedStatement
or
CallableStatement
.
ResultSet.get*()
with a column index < 1
returns misleading error message.
(Bug#27317)
Using ResultSet.get*()
with a column index
less than 1 returns a misleading error message.
(Bug#27317)
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.
(Bug#26789)
PreparedStatement
is not closed in
BlobFromLocator.getBytes()
.
(Bug#26592)
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.
(Bug#26173)
CallableStatements
with
OUT/INOUT
parameters that are "binary"
(BLOB
,
BIT
,
(VAR)BINARY
, JAVA_OBJECT
)
have extra 7 bytes.
(Bug#25715)
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.
(Bug#25624)
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.
(Bug#25517)
BIT(> 1)
is returned as
java.lang.String
from
ResultSet.getObject()
rather than
byte[]
.
(Bug#25328)
User Comments
Add your own comment.