-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
MySQL Connector/J 5.1.1 a new alpha version of the Type-IV pure-Java JDBC driver for MySQL has been released. Version 5.1.1 is suitable for use with any MySQL version including MySQL-4.1, MySQL-5.0, MySQL-5.1 beta or the MySQL-5.2 Falcon "Preview". It is now available in source and binary form from the Connector/J download pages at http://dev.mysql.com/downloads/connector/j/5.1.html 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 http://dev.mysql.com/doc/refman/5.0/en/cj-news.html and "Upgrading" sections http://dev.mysql.com/doc/refman/5.0/en/cj-upgrading.html 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.: http://forge.mysql.com/wiki/Contributing This is the last alpha release of our implementation of the new JDBC-4.0 API, with a beta release planned to follow shortly based on feedback from this release. This alpha release, 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.1 includes the following new features compared to 5.1.0: * Pulled vendor-extension methods of Connection implementation out into an interface to support java.sql.Wrapper functionality from ConnectionPoolDataSource. The vendor extensions are javadoc'd in the com.mysql.jdbc.Connection interface. For those looking further into the driver implementation, it is not an API that is used for plugability of implementations inside our driver (which is why there are still references to ConnectionImpl throughout the code). Incompatible change: Connection.serverPrepare(String) has been re-named to Connection.serverPrepareStatement() for consistency with Connection.clientPrepareStatement(). We've also added server and client prepareStatement() methods that cover all of the variants in the JDBC API. * Similar to Connection, we pulled out vendor extensions to Statement into an interface named "com.mysql.Statement", and moved the Statement class into com.mysql.StatementImpl. The two methods (javadoc'd in "com.mysql.Statement" are enableStreamingResults(), which already existed, and disableStreamingResults() which sets the statement instance back to the fetch size and result set type it had before enableStreamingResults() was called. * 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 you can influence it. (currently experimental). StatementInterceptors are "chainable" when configured by the user, the results returned by the "current" interceptor will be passed on to the next on in the chain, from left-to-right order, as specified by the user in the JDBC configuration property "statementInterceptors". See the sources (fully javadoc'd) for com.mysql.jdbc.StatementInterceptor for more details until we iron out the API and get it documented in the manual. * Externalized the descriptions of connection properties. * 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. * Made it possible to retrieve prepared statement parameter bindings (to be used in StatementInterceptors, primarily). * Row navigation now causes any streams/readers open on the result set to be closed, as in some cases we're reading directly from a shared network packet and it will be overwritten by the "next" row. * 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. * 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. * When unpacking result set rows from result sets without TEXT or BLOB columns, the driver now avoids one copy and reads from the network directly, resulting in an approximate 3% performance increase for most workloads. 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). This release also includes the following cahnges that are also present in Connector/J 5.0.7 (not yet released): * Setting the configuration parameter "useCursorFetch" to "true" for MySQL-5.0+ enables the use of cursors that allow Connector/J to save memory by fetching result set rows in chunks (where the chunk size is set by calling setFetchSize() on a Statement or ResultSet) by using fully-materialized cursors on the server. The driver will will now automatically set "useServerPrepStmts" to "true" when "useCursorFetch" has been set to "true", since the feature requires server-side prepared statements in order to function. * Fixed BUG#28469 - PreparedStatement.getMetaData() for statements containing leading one-line comments is not returned correctly. As part of this fix, we also overhauled detection of DML for executeQuery() and SELECTs for executeUpdate() in plain and prepared statements to be aware of the same types of comments. * Added configuration property "useNanosForElapsedTime" - for profiling/debugging functionality that measures elapsed time, should the driver try to use nanoseconds resolution if available (requires JDK >= 1.5)? * Added configuration property "slowQueryThresholdNanos" - if "useNanosForElapsedTime" is set to "true", and this property is set to a non-zero value the driver will use this threshold (in nanosecond units) to determine if a query was slow, instead of using millisecond units. Note, that if "useNanosForElapsedTime" is set to "true", and this property is set to "0" (or left default), then elapsed times will still be measured in nanoseconds (if possible), but the slow query threshold will be converted from milliseconds to nanoseconds, and thus have an upper bound of approximately 2000 millesconds (as that threshold is represented as an integer, not a long). * Added configuration properties to allow tuning of TCP/IP socket parameters: "tcpNoDelay" - Should the driver set SO_TCP_NODELAY (disabling the Nagle Algorithm, default "true")? "tcpKeepAlive" - Should the driver set SO_KEEPALIVE (default "true")? "tcpRcvBuf" - Should the driver set SO_RCV_BUF to the given value? The default value of '0', means use the platform default value for this property. "tcpSndBuf" - Should the driver set SO_SND_BUF to the given value? The default value of '0', means use the platform default value for this property. "tcpTrafficClass" - Should the driver set traffic class or type-of-service fields? See the documentation for java.net.Socket.setTrafficClass() for more information. * Give more information in EOFExceptions thrown out of MysqlIO (how many bytes the driver expected to read, how many it actually read, say that communications with the server were unexpectedly lost). * Setting "useDynamicCharsetInfo" to "false" now causes driver to use static lookups for collations as well (makes ResultSetMetadata.isCaseSensitive() much more efficient, which leads to performance increase for ColdFusion, which calls this method for every column on every table it sees, it appears). * Driver detects when it is running in a ColdFusion MX server (tested with version 7), and uses the configuration bundle "coldFusion", which sets useDynamicCharsetInfo to "false" (see previous entry), and sets useLocalSessionState and autoReconnect to "true".Enjoy! -Mark - -- Mark Matthews, Architect (Client Connectivity) MySQL, Inc. Chicago, USA - www.mysql.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFGfxy4tvXNTca6JD8RAgWVAJ9ORQdkblthwqLBbAmcUoCk85zrPwCeKNgq 0FGto/xaxXHinK1fmWwXi5Q= =UdOi -----END PGP SIGNATURE----- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
