Version 5.1.35 is a maintenance release of the production 5.1 branch. It is suitable for use with MySQL server versions 5.5, and 5.6.
The failover support by Connector/J has been refactored to be implemented independently of Connector/J's load-balancing feature. This resolves a number of issues including, for example, (1) a failover being triggered inadvertently, (2) a failover process kept trying to connect to an unavailable server (while there was an available one), and (3) the number of active connections kept growing until Connector/J threw an exception when there were successive failovers within the same connection. (The issues are regressions of Bug #75168.) (Bug #20533907, Bug #75885)
A number of new configuration properties have been introduced:
enabledSSLCipherSuites: For setting the enabled cipher suites used by JSSE. This configuration property needs to be set when using Java 7 or lower or MySQL Server Community edition version 5.7.6 or higher.
readOnlyPropagatesToServer: For controlling the implicit propagation of the read-only transaction access mode to the server, which affects optimization for InnoDB read-only transactions.
cacheDefaultTimezone: For improving Connector/J's time zone support; see the changelog entry for Bug #18028319/Bug #71084 below for details.
See the descriptions for these properties in Driver/Datasource Class Names, URL Syntax and Configuration Properties for Connector/J for more details.
Connector/J now exposes the
PreparedStatment.ParseInfoclass for external usage, with no capture of the connection, which allows global, highly-concurrent parse caches to be implemented.
Issues with a number of the regression tests in the Connector/J test suite caused them to fail when they were run against MySQL 5.7.6. Those tests have now been fixed. (Bug #20606107)
Calling the function
Clob.setString()with valid input resulted in a string index out of bounds exception. (Bug #20453712)
Calling the function
Clob.position()resulted in an exception, because the function passed the wrong index value to the
getSubString()function. (Bug #20453712)
When in streaming mode, if Connector/J encountered an exception while reading from the stream, a subsequent call to the
close()method of the result set would put the thread into a blocking state, from which it would not exit. With this fix, the result set can now be properly closed when, due to an error, there is no more data to be loaded from the stream. (Bug #20272931, Bug #75309)
setTimestampmethod failed in a Fabric connection with a null pointer exception. It was because the implementation for the
getCalendarInstanceForSessionOrNewmethod was missing, which has been added by this fix to Connector/J. (Bug #20217686, Bug #75080)
When using JDBC 4 features of Connector/J 5.1 with JDK 6 and above, custom implementations of the interface
LoadBalanceExceptionCheckerfailed to work. This was because most of the JDBC 4-specific classes of Connector/J do not implement a JDBC interface directly, but extend other JDBC 3 classes instead, so that the
LoadBalancingConnectionProxy.isInterfaceJdbc()check did not work. This fix makes the checking work by extending its search to include also the super classes. (Bug #20204783, Bug #75168)
readRemainingMultiPacketsmethod in the
MysqlIOclass returned incorrect results when a row was larger than 16MB in size. This fix corrects the wrong type conversion occurred during the calculation, which caused the problem. (Bug #20112694, Bug #74998)
rs.relative()had been called with an argument smaller than “-1” resulted in a null pointer exception, because
rs.relative()could not handle the argument properly. (Bug #19536760)
All occurrences of the
StringBufferclass in the Connector/J code has been replaced with the
StringBuilderclass, in order to improve code performance. (Bug #19465516, Bug #73595)
Quoted identifiers in some SQL statements were not properly escaped. (Bug #18925727)
java.sql.datevalue was stored incorrectly on the server and also returned incorrectly if the client and the server were in different time zones when
useTimezone=true. This was due to the time-zone conversion performed by Connector/J on the SQL DATE type. To avoid the issue, a new property
noTimezoneConversionForDateTypehas been created for Connector/J, which is set to “true” by default, preventing Connector/J to perform the kind of time-zone conversion that caused this bug.
In addition, another new property
cacheDefaultTimezonehas been created: when it is set to “true” (by default), Connector/J caches the time zone first obtained from the client and uses it throughout the time the application is running. When it is set to “false,” Connector/J becomes aware of time zone changes in the client at runtime that are initiated by calling
java.util.TimeZone.setDefault(zone). (Bug #18028319, Bug #71084)
A deadlock occurred when concurrent prepared statements making use of timestamp objects were executed in a single connection. To avoid this, the locking mechanism involved has been changed, so that the calendar object for the session is only locked when it is actually being used. (Bug #15936413, Bug #67760)
There was an unnecessary call of
newSetTimestampInternal()method of the
PreparedStatement.javaclass, which modified the user-supplied
Calendarobject and might cause side effects for the client application. The unnecessary call has now been eliminated by the fix put in for Bug #18028319/Bug #71084. (Bug #11761585, Bug #54095)