Changes in MySQL Connector/J 5.1.25 (2013-05-01)

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• When connecting to MySQL server 5.6 or later, Connector/J now sends to the server a number of connection attributes that will be exposed in the relevant PERFORMANCE_SCHEMA tables. By default, the following attributes are sent:

  • client_version: version number of MySQL Connector/J

  • client_name: “MySQL Connector Java”

  • client_license: “commercial”" or “GPL,” depending on the build used

  • runtime_vendor: JVM vendor name

  • runtime_version: JVM version

  The list of attributes can be augmented, and the sending of the attributes can be suppressed. See the description for connectionAttributes in Configuration Properties for Connector/J for details.

Bugs Fixed

• The “mysql-connector-java-5.1.24.jar” prepared for maven.org contained the artifact, META-INF/INDEX.LIST, which incorrectly pointed to “mysql-connector-java-5.1.24-bin.jar”. For Connector/J 5.1.25, META-INF/INDEX.LIST has been corrected and now points to “mysql-connector-java-5.1.25.jar”.

  The work around for “mysql-connector-java-5.1.24.jar” prepared for maven.org is to rename the JAR file to “mysql-connector-java-5.1.24-bin.jar” or to download the MySQL Connector/J 5.1.24 driver from http://dev.mysql.com/downloads/connector/j/. (Bug #16574419)

• The getDriverName() function would return “MySQL-AB JDBC Driver” as the driver name. This fix changes the driver name string to “MySQL Connector Java”. (Bug #16436511)

• With the connection option rewriteBatchedStatements=true, after a batch insert, the batchStatement was closed twice. This caused some unnecessary throwing and catching of errors, impacting code performance. This fix nullifies the batchStatement after the first calling of the close() method in order to avoid a second closing. (Bug #69308, Bug #16879267)

• The DatabaseMetaData methods of getFunctions and getFunctionColumns returned information for both stored functions and procedures when value of the connection option useInformationSchema was false. On the other hand, getProcedures and getProcedureColumns always return information for both stored procedures and functions. The behaviours of the four functions are inconsistent with the idea introduced since JDBC4 to separate the “get” functions for stored functions and procedures. The functions are modified as follows:

  • getFunctions and getFunctionColumns now only return information for stored functions (not for stored procedures), irrespective of the value of useInformationSchema.

  • For getProcedures and getProcedureColumns, in order to maintain backward compatibility with pre-JDBC4 implementations, a new connection option, getProceduresReturnsFunctions, is created, whose default value of true makes getProcedures and getProcedureColumns return information for both stored procedures and functions. Setting the option to false makes the functions return only information for stored procedures.

  (Bug #69298, Bug #16845965)

• ReplicationConnection.isMasterConnection(), which is intended to check if the current connection is the master connection, would always return “false”. This fix implements logic that returns “true” if the current connection is the master connection. (Bug #68763, Bug #16545334)

• When using Connector/J in a replication deployment, all of the slave connections would not be pinged. This fix ensures that all active physical connections to slaves are pinged, and that communication exceptions are thrown if:

  • The master connection ping fails, and the connection is currently set to use the master connection via Connection.setReadOnly(false).

  • The Connection object is set to use the slave via Connection.setReadOnly(true), and the currently-selected slave connection ping fails.

  (Bug #68733, Bug #16526938)

• Producing Connector/J JAR packages in Eclipse using Ant tasks would result in a JAR file without compiled class files. Compile-related tasks in the Ant script would direct compilation targets to the bin directory (for Eclipse compatibility), while JAR related tasks were directed to {buildDir}/${fullProdName}. This fix changes the JAR task reference to ${compiler.output} instead of {buildDir}/${fullProdName}. (Bug #68664, Bug #16486957)

• Tomcat failed to stop abandoned connection cleanup threads. The fix for Bug#65909 introduced the ability to stop daemon threads started by the Connector/J driver but it also cleared references from daemon threads to the parent classloader. When the clearReferencesStopThreads property is set to “true” in context.xml, Tomcat analyzes classloaders to detect and stop lost threads. This fix ensures that abandoned connection cleanup threads retain a reference to the parent classloader. (Bug #68556, Bug #16443387)

• The DatabaseMetaData.getProcedureColumns() method returned wrong COLUMN_TYPE values. (Bug #68307, Bug #16707803)

• An exception occurred if NULL was passed to a stored procedure INOUT parameter. (Bug #60816, Bug #12800874)

• The result set returned by getTables did not contain all the columns as specified in the JDBC specification. Even though the missing columns are not meaningful to MySQL, the getTables method is modified to add null fields to the result set in order to make it compliant with the JDBC specification. Other methods including getColumns, getFunctionColumns, getFunctions, getProcedureColumns, and getUDTs are also modified to address the same issue pertaining to them. (Bug #44451, Bug #11753081)