オリジナル版：http://lists.mysql.com/java/9159
バージョン5.1版での最初の製品版リリースであるMySQL Connector/J 5.1.5が リリースされました。Connector/Jは、MySQL用のタイプ4のpure-Java JDBCドライバです。
バージョン5.1.5は、MySQL-4.1、MySQL-5.0、MySQL-5.1ベータ版、MySQL-6.0ファルコンプレビュー用を含んだいくつかのMySQLのバージョンでの使用にふさわしいリリースです。
バージョン5.1.5は、http://dev.mysql.com/downloads/connector/j/5.1.htmlおよびミラーサイトのConnector/Jダウンロードページからソースおよびバイナリ形式で入手可能です。(すべてのミラーサイトが現在において最新であるとは限らないかもしれないことに注意してください。あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。)
いつものことですが、アプリケーションに影響を及ぼす動作変更を把握するには、アップグレードの前に、マニュアルの変更ログ(http://dev.mysql.com/doc/refman/5.0/en/cj-news.html)と"Upgrading"の節(http://dev.mysql.com/doc/refman/5.0/en/cj-upgrading.html)をチェックするようお勧めします。
バグレポート、バグ修正、パッチ等の情報をお待ちしておりますので、以下のページをご利用ください。
http://forge.mysql.com/wiki/Contributing
バージョン5.1.5は新たなパフォーマンスの特徴に加えて、新たなJDBC-4.0 APIを実装した初めての製品版リリースです。
バージョン5.1を製品版にリリースする前に、5.0版からのぎりぎりの更新は控えたいと思いました。そのため、公開を行なわなかった内部リリース5.1.4が存在したことにご注意ください。
以下は、Connector/J 5.1.5の5.1.3に対するパフォーマンス改善、機能の追加および変更情報です。
- - Added "autoSlowLog" configuration property, overrides "slowQueryThreshold*" properties, driver determines slow queries by those that are slower than 5 * stddev of the mean query time (outside the 96% percentile). - - FixedBUG#28256- When connection is in read-only mode, queries that are wrapped in parentheses incorrectly identified as DML. 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. - - 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). - - Improved connection establishment time by 25% through selective retrieval of server variables. - - Improved ResultSet.getString(). It's now twice as fast, compared to 5.0. - - 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. This change leads to substantial improvements in memory usage by avoiding copying data or allocating large blocks of memory when using "streaming" result sets or when dealing with large rows. - - Added experimental support for connection lifecycle "interceptors", which enable notifcation of lifecycle events such as connection creation, destruction and transaction demarcation and allow code to be plugged in to influence the behavior of these events, see the source code of related interfaces athttp://tinyurl.com/24g28yand http://tinyurl.com/29l4xtfor more details. - - 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). - - 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. - - 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: - - 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? - - 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. - - XAConnections now start in auto-commit mode (as per JDBC-4.0 specification clarification). - - Driver will now fall back to sane defaults for max_allowed_packet and net_buffer_length if the server reports them incorrectly (and will log this situation at WARN level, since it's actually an error condition). - - FixedBUG#27182- Connection.getServerCharacterEncoding() doesn't work for servers with version >= 4.1. - - FixedBug#27412- cached metadata with PreparedStatement.execute() throws NullPointerException. - - FixedBUG#27867- Schema objects with identifiers other than the connection character aren't retrieved correctly in ResultSetMetadata. - - FixedBUG#27915- DatabaseMetaData.getColumns() doesn't contain SCOPE_* or IS_AUTOINCREMENT columns. - - FixedBUG#27916- UNSIGNED types not reported via DBMD.getTypeInfo(), and capitalization of type names is not consistent between DBMD.getColumns(), RSMD.getColumnTypeName() and DBMD.getTypeInfo(). This fix also ensures that the precision of UNSIGNED MEDIUMINT and UNSIGNED BIGINT is reported correctly via DBMD.getColumns(). - - FixedBUG#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. - - FixedBUG#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. - - FixedBUG#29106- Connection checker for JBoss didn't use same method parameters via reflection, causing connections to always seem "bad". - - FixedBUG#29852- Closing a load-balanced connection would cause a ClassCastException. - - FixedBUG#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. - - FixedBUG#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. - - FixedBUG#30851, NPE with null column values when "padCharsWithSpace" is set to "true". - FixedBug#30892setObject(int, Object, int, int) delegate in PreparedStatmentWrapper delegates to wrong method. - - FixedBUG#31053- Connections established using URLs of the form "jdbc:mysql:loadbalance://" weren't doing failover if they tried to connect to a MySQL server that was down. The driver now attempts connections to the next "best" (depending on the load balance strategy in use) server, and continues to attempt connecting to the next "best" server every 250 milliseconds until one is found that is up and running or 5 minutes has passed.
If the driver gives up, it will throw the last-received SQLException.