Bugs fixed:
        In the class
        com.mysql.jdbc.jdbc2.optional.SuspendableXAConnection,
        which is used when
        pinGlobalTxToPhysicalConnection=true, there
        is a static map (XIDS_TO_PHYSICAL_CONNECTIONS) that tracks the
        Xid with the XAConnection, however this map was not populated.
        The effect was that the
        SuspendableXAConnection was never pinned to
        the real XA connection. Instead it created new connections on
        calls to start, end,
        resume, and prepare.
       (Bug#46925)
When using the ON DUPLICATE KEY UPDATE functionality together with the rewriteBatchedStatements option set to true, an exception was generated when trying to execute the prepared statement:
INSERT INTO config_table (modified,id_) VALUES (?,?) ON DUPLICATE KEY UPDATE modified=?
The exception generated was:
java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is 2). at com.sag.etl.job.processors.JdbcInsertProcessor.flush(JdbcInsertProcessor.java:135) ...... Caused by: java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is 2). at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) at com.mysql.jdbc.PreparedStatement.checkBounds(PreparedStatement.java:3657) at com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:3641) at com.mysql.jdbc.PreparedStatement.setBytesNoEscapeNoQuotes(PreparedStatement.java:3391) at com.mysql.jdbc.PreparedStatement.setOneBatchedParameterSet(PreparedStatement.java:4203) at com.mysql.jdbc.PreparedStatement.executeBatchedInserts(PreparedStatement.java:1759) at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1441) at com.sag.etl.job.processors.JdbcInsertProcessor.flush(JdbcInsertProcessor.java:131) ... 16 more
        When Connector/J encountered an error condition that caused it
        to create a CommunicationsException, it tried
        to build a friendly error message that helped diagnose what was
        wrong. However, if there had been no network packets received
        from the server, the error message contained the following
        incorrect text:
      
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.
        The getSuperTypes method returned a result
        set with incorrect names for the first two columns. The name of
        the first column in the result set was expected to be
        TYPE_CAT and that of the second column
        TYPE_SCHEM. The method however returned the
        names as TABLE_CAT and
        TABLE_SCHEM for first and second column
        respectively.
       (Bug#44508)
SQLException for data truncation error gave the error code as 0 instead of 1265. (Bug#44324)
        Calling ResultSet.deleteRow() on a table with
        a primary key of type BINARY(8) silently
        failed to delete the row, but only in some repeatable cases. The
        generated DELETE statement generated
        corrupted part of the primary key data. Specifically, one of the
        bytes was changed from 0x90 to 0x9D, although the corruption
        appeared to be different depending on whether the application
        was run on Windows or Linux.
       (Bug#43759)
Accessing result set columns by name after the result set had been closed resulted in a NullPointerException instead of a SQLException. (Bug#41484)
        QueryTimeout did not work for batch
        statements waiting on a locked table.
      
When a batch statement was issued to the server and was forced to wait because of a locked table, Connector/J only terminated the first statement in the batch when the timeout was exceeded, leaving the rest hanging. (Bug#34555)
        The parseURL method in class
        com.mysql.jdbc.Driver did not work as
        expected. When given a URL such as
        “jdbc:mysql://www.mysql.com:12345/my_database” to
        parse, the property PORT_PROPERTY_KEY was
        found to be null and the
        HOST_PROPERTY_KEY property was found to be
        “www.mysql.com:12345”.
      
          Connector/J has been fixed so that it will now always fill in
          the PORT property (using 3306 if not
          specified), 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 section of code used to
          generate lists of hosts, both for load-balanced and fault
          tolerant connections and their tests.
        
        Attempting to delete rows using
        ResultSet.deleteRow() did not delete rows
        correctly.
       (Bug#27431)
        The setDate method silently ignored the
        Calendar parameter. The code was implemented as follows:
      
public void setDate(int parameterIndex, java.sql.Date x, Calendar cal) throws SQLException {
   setDate(parameterIndex, x);
}        
      
        From reviewing the code it was apparent that the Calendar
        parameter cal was ignored.
       (Bug#23584)

User Comments
Add your own comment.