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.