D.6.1.2. Changes in MySQL Connector/J 5.1.13 (24 June 2010)

Fixes bugs found since release 5.1.12.

Functionality added or changed:

  • Connector/J did not support utf8mb4 for servers 5.5.2 and newer.

    Connector/J now auto-detects servers configured with character_set_server=utf8mb4 or treats the Java encoding utf-8 passed using characterEncoding=... as utf8mb4 in the SET NAMES= calls it makes when establishing the connection. (Bug#54175)

Bugs fixed:

  • The method unSafeStatementInterceptors() contained an erroneous line of code, which resulted in the interceptor being called, but the result being thrown away. (Bug#53041)

  • There was a performance regression of roughly 25% between r906 and r907, which appeared to be caused by pushing the Proxy down to the I/O layer. (Bug#52534)

  • Logic in implementations of LoadBalancingConnectionProxy and LoadBalanceStrategy behaved differently as to which SQLExceptions trigger failover to a new host. The former looked at the first two characters of the SQLState:

    if (sqlState.startsWith("08"))
    ...
    

    The latter used a different test:

    if (sqlEx instanceof CommunicationsException
      || "08S01".equals(sqlEx.getSQLState())) {
    ...
    

    This meant it was possible for a new Connection object to throw an Exception when the first selected host was unavailable. This happened because MySqlIO.createNewIO() could throw an SQLException with a SQLState of “08001”, which did not trigger the “try another host” logic in the LoadBalanceStrategy implementations, so an Exception was thrown after having only attempted connecting to a single host. (Bug#52231)

  • In the file DatabaseMetadata.java, the function private void getCallStmtParameterTypes failed if the parameter was defined over more than one line by using the '\n' character. (Bug#52167)

  • The catalog parameter, PARAM_CAT, was not correctly processed when calling for metadata with getMetaData() on stored procedures. This was because PARAM_CAT was hardcoded in the code to NULL. In the case where nullcatalogmeanscurrent was true, which is its default value, a crash did not occur, but the metadata returned was for the stored procedures from the catalog currently attached to. If, however, nullcatalogmeanscurrent was set to false then a crash resulted.

    Connector/J has been changed so that when NULL is passed as PARAM_CAT it will not crash when nullcatalogmeanscurrent is false, but rather iterate all catalogs in search of stored procedures. This means that PARAM_CAT is no longer hardcoded to NULL (see Bug#51904). (Bug#51912)

  • A load balanced Connection object with multiple open underlying physical connections rebalanced on commit(), rollback(), or on a communication exception, without validating the existing connection. This caused a problem when there was no pinging of the physical connections, using queries starting with “/* ping */”, to ensure they remained active. This meant that calls to Connection.commit() could throw a SQLException. This did not occur when the transaction was actually committed; it occurred when the new connection was chosen and the driver attempted to set the auto-commit or transaction isolation state on the newly chosen physical connection. (Bug#51783)

  • The rollback() method could fail to rethrow a SQLException if the server became unavailable during a rollback. The errant code only rethrew when ignoreNonTxTables was true and the exception did not have the error code 1196, SQLError.ER_WARNING_NOT_COMPLETE_ROLLBACK. (Bug#51776)

  • When the allowMultiQueries connection string option was set to true, a call to Statement.executeBatch() scanned the query for escape codes, even though setEscapeProcessing(false) had been called previously. (Bug#51704)

  • When a StatementInterceptor was used and an alternate ResultSet was returned from preProcess(), the original statement was still executed. (Bug#51666)

  • Objects created by ConnectionImpl, such as prepared statements, hold a reference to the ConnectionImpl that created them. However, when the load balancer picked a new connection, it did not update the reference contained in, for example, the PreparedStatement. This resulted in inserts and updates being directed to invalid connections, while commits were directed to the new connection. This resulted in silent data loss. (Bug#51643)

  • jdbc:mysql:loadbalance:// would connect to the same host, even though loadBalanceStrategy was set to a value of random, and multiple hosts were specified. (Bug#51266)

  • An unexpected exception when trying to register OUT parameters in CallableStatement.

    Sometimes Connector/J was not able to register OUT parameters for CallableStatements. (Bug#43576)

Copyright © 2010-2024 Platon Technologies, s.r.o.           Home | Man pages | tLDP | Documents | Utilities | About
Design by styleshout