MySQL Connector/J 5.1.7がリリースされました。


バージョン5.1版での製品版保守リリースであるMySQL Connector/J 5.1.7が リリースされました。Connector/Jは、MySQL用のタイプ4のpure-Java JDBCドライバです。

バージョン5.1.7は、MySQL-4.1、MySQL-5.0、MySQL-5.1 RC、MySQL-6.0開発リリースを含んだいくつかのMySQLのバージョンでの使用にふさわしいリリースです。






以下は、Connector/J 5.1.7の変更情報です。

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

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

- FixedBUG#33861- Added global blacklist for 
LoadBalancingConnectionProxy and implemented in RandomBalanceStrategy 
and BestResponseTimeBalanceStrategy.  Added new property, 
"loadBalanceBlacklistTimeout", to control how long a server lives in 
the global blacklist. (Thanks to Todd Farmer in the support team for 
implementing this feature, and for Shawn Green in the support team for 
testing it!)

- FixedBUG#38782- Possible IndexOutOfBoundsException in random load 
balancing strategy.

- FixedBUG#39784- invalidateCurrentConnection() does not manage 
global blacklist when handling connection exceptions.

- FixedBUG#40031- Adding support for CallableStatement.execute() to 
call stored procedures that are defined as NO SQL or SQL READ DATA 
when failed over to a read-only slave with replication driver.

- Use socket timeouts for JDBC-4.0's Connection.isValid(int timeout) 
instead of timer tasks, for scalability. As a side effect internally, 
any communications with the database can use a timeout different than 
the configured timeout, but this isn't currently used.

- Added connection property "useLocalTransactionState" which 
configures if the driver use the in-transaction state provided by the 
MySQL protocol to determine if a commit() or rollback() should 
actually be sent to the database. (disabled by default).

- FixedBUG#39962- ResultSet.findColumn() is slow for applications 
that call it too often (we're looking at -you- Hibernate). We're using 
TreeMaps to get case-insensitive comparisons (required for JDBC 
compliance), but they can be slower than hash maps, so using the 
approach Alex Burgel points out in this bug seems to help.

- FixedBUG#39611- ReplicationConnection never sends queries to last 
host in slave list.

- FixedBUG#35660- Calling equals() on connections created with 
"jdbc:mysql:loadbalance:"   URLs did not have the same behavior as 
"plain" connections. The behavior we use is the implementation in 
java.lang.Object, load-balanced connections just happened to be using 
a java.lang.reflect.Proxy which required some custom behavior in  
equals() to make it work the same as "plain" connections.

  Note that there is no *specified* equals contract for JDBC 
connections in the JDBC specification itself, but the test makes sure 
that our implementation is at least consistent.

As well as the following general bug fixes:

- FixedBUG#35170- ResultSet.isAfterLast() doesn't work with for 
streaming result sets.

- FixedBUG#35199- Parse error for metadata in stored function.

- FixedBUG#35415- When result set is from views without access to 
underlying columns and is opened with CONCUR_UPDATABLE, don't throw 
SQLExceptions when checking updatability due to access permissions, 
instead return CONCUR_READONLY from getConcurrency.

- FixedBUG#35666- NullPointerException when using 
"logSlowQueries=true" with server-side prepared statements enabled.

- FixedBUG#35810- Properties set in URLs and then passed to 
DataSources via setUrl()  did not take effect in certain 
circumstances. This also fixes related bugsBUG#13261and BUG#35753.

- FixedBUG#36051- ResultSet.getTime() won't accept value of '24' 
for hours component of a java.sql.Time.

- FixedBUG#36830- DBMD.getColumns() doesn't return correct 
COLUMN_SIZE for SET columns. The logic wasn't accounting for the ","s 
in the column size.

        - FixedBUG#35610,BUG#35150- ResultSet.findColumn() and 
ResultSet.get...(String) doesn't allow  column names to be used, and 
isn't congruent with ResultSetMetadata.getColumnName().

           By default, we follow the JDBC Specification here, in that 
the 4.0 behavior  is correct. Calling programs should use 
ResultSetMetaData.getColumnLabel() to dynamically determine the 
correct "name" to pass to ResultSet.findColumn() or ResultSet.get...
(String) whether or not the query specifies an alias via "AS" for the 
column. ResultSetMetaData.getColumnName() will return the actual name 
of the column, if it exists, and this name can *not* be used as input 
to ResultSet.findColumn() or ResultSet.get...(String).

The JDBC-3.0 (and earlier) specification has a bug, but you can get 
the buggy behavior (allowing column names *and* labels to be used for 
ResultSet.findColumn() and get...(String)) by setting  
"useColumnNamesInFindColumn" to "true".

         - FixedBUG#35489- Prepared statements from pooled 
connections cause NPE when closed() under JDBC-4.0.

- The number and position of columns for "SHOW INNODB STATUS" changed 
in MySQL-5.1, which caused the   
"includeInnodbStatusInDeadlockExceptions" feature to not show data 
about the deadlock.

- Implemented support of INFORMATION_SCHEMA for 
DatabaseMetadata.getTables() (views there are available as "SYSTEM 
TABLE"), and thus   also made INFORMATION_SCHEMA tables available via 

- FixedBUG#39352, "INSERT ... ON DUPLICATE KEY UPDATE" doesn't 
return "0" for un-affected rows. This requires the driver to not  send 
the "CLIENT_FOUND_ROWS" flag to the server when it connects if the 
connection property "useAffectedRows" is set to "true",  which breaks 
JDBC-compliance, but currently there is no other way to get correct 
return values from the server.

- FixedBUG#38747- ResultSets in "streaming" mode throw an exception 
when closed when the connection is set as "read-only".

- FixedBUG#37570- Can't use non-latin1 passwords. Added connection 
property "passwordCharacterEncoding". Leaving this set to  the default 
value (null), uses the platform character set, which works for 
ISO8859_1 (i.e. "latin1") passwords. For passwords  in other character 
encodings, the encoding will have to be specified with this property, 
as it's not possible for the driver to  auto-detect this.

- FixedBUG#39911- We don't retrieve nanos correctly when -parsing- 
a string for a TIMESTAMP. MySQL itself doesn't support micros   or 
nanos in timestamp values, but if they're stored as strings, 
historically we try and parse the nanos portion as well.  
Unfortunately we -interpreted- them as micros. This fix includes 
correcting that behavior, and setting the milliseconds portion of such 
TIMESTAMPs to a correct value as well.

- FixedBUG#39956- Statement.getGeneratedKeys() doesn't respect the 
'auto_increment_increment' value. We now grab the *session-scoped* 
value, and use that. Beware that using "cacheServerConfig=true" will 
cause us to cache this value, so new connections won't see changes 
that are applied via something like "init-sql".

- FixedBUG#34185- Statement.getGeneratedKeys() does not raise 
exception when statement was not  created with 

- Using autoGenerateTestcaseScript=true now logs all statements, 
regardless or not if they cause errors when processed by MySQL.  A 
"clock" value (millis since epoch) was added in the comment that is 
pre-pended with the idea that it can then be used when post-processing 
output to sequence things correctly for a multi-threaded testcase, or 
to replay the test case with the correct think times.