MySQL Connector/J 5.1.9 Has Been Released!

[Mark Matthews]

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/