MySQL Lists are EOL. Please join:

List:MySQL and Java« Previous MessageNext Message »
From:Mark Matthews Date:September 10 2007 6:17pm
Subject:MySQL Connector/J 5.1.3 RC is available!
View as plain text  
Hash: SHA1


MySQL Connector/J 5.1.3 RC, a new release candidate of the Type-IV pure-Java JDBC driver
for MySQL has been released. 

Version 5.1.3 is suitable for use with any MySQL version including MySQL-4.1, MySQL-5.0,
MySQL-5.1 beta or the MySQL-6.0 Falcon alpha release.

It is now available in source and binary form from the Connector/J download pages at

and mirror sites (note that not all mirror sites may be up to date at this point of time -
if you can't find this version on some mirror, please try again later or choose another
download site.)

As always, we recommend that you check the change log 

and "Upgrading" sections 

in the manual before upgrading as well as the "CHANGES" file in the download archive to be
aware of changes in behavior that might affect your application. 

We welcome and appreciate your feedback, bug reports, bug fixes, patches etc.:

This is the release candidate of our implementation of the new JDBC-4.0 API, along with
some new performance features.

This release candidate, as any other pre-production release, should not be installed on
production level systems or systems with critical data. It is good practice to back up
your data before installing any new version of software. Although MySQL has worked very
hard to ensure a high level of quality, protect your data by making a backup as you would
for any other software pre-production release.

MySQL Connector/J 5.1.3 includes the following new feature compared to 5.1.2:

* Setting "useBlobToStoreUTF8OutsideBMP" to "true" tells the driver to treat
[MEDIUM/LONG]BLOB columns as [LONG]VARCHAR columns holding text encoded in UTF-8 that has
characters outside the BMP (4-byte encodings), which MySQL server can't handle natively.

Set "utf8OutsideBmpExcludedColumnNamePattern" to a regex so that column names matching the
given regex will still be treated as BLOBs The regex must follow the patterns used for the
 java.util.regex package. The default is to exclude no columns, and include all columns.

Set "utf8OutsideBmpIncludedColumnNamePattern" to specify exclusion rules to
utf8OutsideBmpExcludedColumnNamePattern". The regex must follow the patterns used for the
java.util.regex package.

* New methods on com.mysql.jdbc.Statement: setLocalInfileInputStream() and

    * setLocalInfileInputStream() sets an InputStream instance that will be used to send
data    to the MySQL server for a "LOAD DATA LOCAL INFILE" statement rather than a
FileInputStream or URLInputStream that represents the path given as an argument to the

      This stream will be read to completion upon execution of a "LOAD DATA LOCAL INFILE"
statement, and will automatically be closed by the driver, so it needs to be reset before
each call to execute*() that would cause the MySQL server to request data to fulfill the

      If this value is set to NULL, the driver will revert to using a FileInputStream or
URLInputStream as required.

    * getLocalInfileInputStream() returns the InputStream instance that will be used to
send     data in response to a "LOAD DATA LOCAL INFILE" statement.

      This method returns NULL if no such stream has been set via

* The driver now connects with an initial character set of "utf-8" solely for the purposes
of authentication to allow usernames and database names in any character set to be used in

* Errors encountered during Statement/PreparedStatement/CallableStatement.executeBatch()
when "rewriteBatchStatements" has been set to "true" now return BatchUpdateExceptions
according to the setting of "continueBatchOnError".

If "continueBatchOnError" is set to "true", the update counts for the "chunk" that were
sent as one unit will all be set to EXECUTE_FAILED, but the driver will attempt to process
the remainder of the batch. You can determine which "chunk" failed by looking at the
update counts returned in the BatchUpdateException.

If "continueBatchOnError" is set to "false", the update counts returned will contain all
updates up-to and including the failed "chunk", with all counts for the failed "chunk" set

Since MySQL doesn't return multiple error codes for multiple-statements, or for
multi-value INSERT/REPLACE, it is the application's responsibility to handle determining
which item(s) in the "chunk" actually failed.

* Statement.setQueryTimeout()s now affect the entire batch for batched statements, rather
than the individual statements that make up the batch.

The following features are new, compared to the 5.0 series of Connector/J:

  * JDBC-4.0 ease-of-development features including auto-registration with the
DriverManager via the service provider mechanism, standardized Connection validity checks
and categorized SQLExceptions based on recoverability/retry-ability and class of the
underlying error.

  * JDBC-4.0 standardized unwrapping to interfaces that include vendor extensions.

  * Support for JDBC-4.0 XML processing via JAXP interfaces to DOM, SAX and StAX.

  * JDBC-4.0 support for setting per-connection client information (which can be viewed in
the comments section of a query via "SHOW PROCESSLIST" on a MySQL server, or can be
extended to support custom persistence of the information via a public interface).

  * Support for JDBC-4.0 NCHAR, NVARCHAR and NCLOB types.

  * The driver will automatically adjust the server session variable "net_write_timeout"
when it determines its been asked for a "streaming" result, and resets it to the previous
value when the result set has been consumed. (The configuration property is named
"netTimeoutForStreamingResults", with a unit of seconds, the value '0' means the driver
will not try and adjust this value).

  * Added experimental support for statement "interceptors" via the   
com.mysql.jdbc.StatementInterceptor interface, examples are in
com/mysql/jdbc/interceptors.  Implement this interface to be placed "in between" query
execution, so that it can be influenced (currently experimental).

  * The data (and how it's stored) for ResultSet rows are now behind an interface which
allows us (in some cases) to allocate less memory per row, in that for "streaming" result
sets, we re-use the packet used to read rows, since only one row at a time is ever active.

  * The driver now picks appropriate internal row representation (whole row in one buffer,
or individual byte[]s for each column value) depending on heuristics, including whether or
not the row has BLOB or TEXT types and the overall row-size. The threshold for row size
that will cause the driver to use a buffer rather than individual byte[]s is configured by
the configuration property "largeRowSizeThreshold", which has a default value of 2KB.

  * Setting "rewriteBatchedStatements" to "true" now causes CallableStatements with
batched arguments to be re-written in the form "CALL (...); CALL (...); ..." to send the
batch in as few client-server round trips as possible.

This release also includes the following changes that are also present in Connector/J
5.0.8 (not yet released):

* Fixed BUG#30550, executeBatch() would fail with an ArithmeticException and/or
NullPointerException when the batch had zero members and "rewriteBatchedStatements" was
set to "true" for the connection.

* Added two configuration parameters (both default to "false")
   * blobsAreStrings  - Should the driver always treat BLOBs as Strings specifically to
work around dubious metadata returned by the server for GROUP BY clauses?

   * functionsNeverReturnBlobs - Should the driver always treat data from                 
                      functions returning BLOBs as Strings - specifically to work around
dubious metadata                                         returned by the server for GROUP
BY clauses?

* Fixed BUG#29106 - Connection checker for JBoss didn't use same method parameters via
reflection, causing connections to always seem "bad".

* Fixed BUG#30664 - Note that this fix only works for MySQL server versions 5.0.25 and
newer, since earlier versions didn't consistently return correct metadata for functions,
and thus results from subqueries and functions were indistinguishable from each other,
leading to type-related bugs.

* Fixed BUG#28972 - DatabaseMetaData.getTypeInfo() for the types DECIMAL and NUMERIC will
return a precision of 254 for server versions older than 5.0.3, 64 for versions
5.0.3-5.0.5 and 65 for versions newer than 5.0.5.

* Fixed BUG#29852 - Closing a load-balanced connection would cause a ClassCastException.

* Fixed BUG#27867 - Schema objects with identifiers other than the connection character
aren't retrieved correctly in ResultSetMetadata.

* Fixed BUG#28689 - CallableStatement.executeBatch() doesn't work when connection property
"noAccessToProcedureBodies" has been set to "true".

The fix involves changing the behavior of "noAccessToProcedureBodies",in that the driver
will now report all paramters as "IN" paramters but allow callers to call
registerOutParameter() on them without throwing an exception.

* Fixed BUG#27182 - Connection.getServerCharacterEncoding() doesn't work for servers with
version >= 4.1.

* Fixed BUG#27915 - DatabaseMetaData.getColumns() doesn't contain SCOPE_* or

* Fixed BUG#30851, NPE with null column values when "padCharsWithSpace" is set to "true".

* Specifying a "validation query" in your connection pool that starts with "/* ping */"
_exactly_ will cause the driver to instead send a ping to the server and return a fake
result set (much   lighter weight), and when using a ReplicationConnection or a
LoadBalancedConnection, will send the ping across all active connections.

* Fixed Bug#30892 setObject(int, Object, int, int) delegate in PreparedStatmentWrapper
delegates to wrong method.


- -- 
Mark Matthews, Architect (Client Connectivity)
MySQL, Inc. Chicago, USA -
Version: GnuPG v1.4.6 (MingW32)


MySQL Connector/J 5.1.3 RC is available!Mark Matthews10 Sep