From: Mark Matthews (markmsun.com)
Date: Mon Sep 21 2009 - 09:41:58 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

MySQL Connector/J 5.1.9, a maintenance release of the production
5.1branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

Version 5.1.9 is suitable for use with any MySQL version including
MySQL-4.1, MySQL-5.0, MySQL-5.1 or the MySQL-5.4 performance
release.

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.1/en/cj-news.html

and "Upgrading" sections

http://dev.mysql.com/doc/refman/5.1/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.

I'd also like to take a minute to welcome and thank Jess Balint (on
the CC) to the development team for Connector/J. He's handled a good
chunk of bug fixes for this release, as well as doing the qa and
release engineering work. Thanks Jess!

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

http://forge.mysql.com/wiki/Contributing

MySQL Connector/J 5.1.9 includes the following changes targeted at
scalability and performance:

    - Fix for a variant of Bug#41484 - ResultSet.find*(String) failed
when using cached result set metadata.

    - Added a new option, "queryTimeoutKillsConnection", when set to
"true" will cause timeouts set by Statement.setQueryTimeout() to
forcibly kill the connection, not just the query.

    - Fixed Bug#46788 - Batched prepared statements with ON DUPLICATE
KEY UPDATE are rewritten incorrectly when when there are parameters as
part of the UPDATE clause. Statements of this form can not be
rewritten as multi-value INSERTs so they are rewritten into multi-
statements instead.

As well as the following general bug fixes and improvements:

    - The driver has been OSGi-ified. The bundle symbolic name is
"com.mysql.jdbc", see META-INF/MANIFEST.MF to see what interfaces we
export.

    - Fixed BUG#45040, adding missing tags from SVN import to BZR
branch for 5.1.

    - Fixed Bug#27431 - ResultSet.deleteRow() advances the cursor. The
driver now places the cursor on the prior row in the result set, or
before the start of the result set if the result set is empty after
the deletion.

    - Fixed Bug#43759 - ResultSet.deleteRow() generates corrupt DELETE
statement for primary keys with binary data.

    - Fixed Bug#46925 - Suspendable XA connections were not pinned to
the XID for the global transaction, leading to failure when attempting
to suspend/resume/commit from different logical XA connections.

    - Fixed Bug#44508 - DatabaseMetadata.getSuperTypes() returns
result set with incorrect column names.

    - Fixed BUG#32216, "PORT" property filled in by Driver.parseURL()
not always present. The driver will now always fill in the
"PORT" (using 3306 if not specified) property, and the "HOST"
property (using "localhost" if not specified) when parseURL() is
called. The driver also parses a list of hosts into HOST.n and PORT.n
properties as well as adding a property "NUM_HOSTS" for the number of
hosts it has found. If a list of hosts is passed to the driver, "HOST"
and "PORT" will be set to the values given by "HOST.1" and "PORT.1"
respectively. This change has centralized and cleaned up a large swath
of code used to generate lists of hosts, both for load-balanced and
fault tolerant connections and their tests.

    - Fixed the ResultSet side of BUG#23584 - Calendar discarded when
retrieving dates from server-side prepared statements. The other cases
of this bug were fixed when "useLegacyDatetimeCode=false" became the
default.

    - Fixed BUG#46637 - When the driver encounters an error condition
that causes it to create a CommunicationsException, it tries to build
a friendly error message that helps diagnose what is wrong. However,
if there has been no network packets received from the server, the
error message contains bogus information like:

      "The last packet successfully received from the server was
1,249,932,468,916 milliseconds ago.
      The last packet sent successfully to the server was 0
milliseconds ago."

      Now the error message states that it has never received any
packets from the server in this scenario.

    - Fixed Bug#44324 - Data truncation exceptions did not return the
vendor error code from the server. Note that the vendor error code is
not hard-coded to 1265 as in the bug report, because the server
returns different error codes for different types of truncations, and
we did not want to mask those.

Enjoy!

        -Mark
--
Mark Matthews, Architect - Enterprise Tools
MySQL Sun Microsystems, Inc., http://www.sun.com/mysql/

--
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]