I’m pleased to announce: MySQL Connector/J 5.1.37 Maintenance Release is now available.

MySQL Connector/J can be downloaded from the official distribution channels MySQL Downloads and The Central repository. Commercial license version is available for download at My Oracle Support.

As always, we recommend that you check the “CHANGES” file in the
download archive and/or the release notes to be aware of changes in behavior that might affect your application.

MySQL Connector/J 5.1.37 includes several bug fixes and other improvements. I’d like to …

I’m pleased to announce that Connector/J has a new home.

Just as several other MySQL products, Connector/J source code management moved to Git and, pretty much as expected, to GitHub. Our reasoning is nothing else than listening to our users demands and trying to follow best trends and practices. There was nothing significantly wrong with Bazaar and Launchpad, as they served us well for the last seven years. It was just time to move on.

Rest assured, all will work as before, no complications no hassles. Our public GitHub repository will expose Connector/J source code as it is in the latest generally available (GA) release, as it has been for the last years.

From now on you will find …

It's been almost a year now since the initial release of MySQL Fabric. It is maturing and reached a GA state earlier this year as part of MySQL Utilities 1.4. Developers and architects are evaluating it for their applications, learning the capabilities of the system, and providing feedback for future features and usability enhancements. Connector/J has supported Fabric from the very beginning and continues to support the latest features. This blog post is an introductory level guide to using Fabric for high-availability from Java applications. Sharding features and Java APIs will be covered in a later post. The commands shown and feature descriptions are current for Fabric 1.5.1. In addition, Connector/J 5.1.32 and later support only Fabric 1.5 due to communication protocol differences from Fabric 1.4.

High-availability is a core concept in Fabric and is implemented by HA groups. An HA group is a set of servers configured with MySQL …

Today marks the release of several exciting pieces of software from Oracle. In addition to MySQL server 5.7.4 DMR, MySQL Fabric is out as a release candidate 1.4.2 and Connector/J 5.1.30 has full support. MySQL Fabric is a new way to implement high-availability and scale-out with MySQL server. It provides a way to group sets of servers into high-availability groups with automatic replication configuration. If scale-out is important, sharding can be defined in terms of these high-availability groups.

To use Connector/J with Fabric, you only need to add the jar to your classpath. If you are still using Java 5, you will need to manually load the com.mysql.fabric.jdbc.FabricMySQLDriver class to register the driver. Fabric-aware connections are made with a JDBC URL of the form jdbc:mysql:fabric://host:port/db. Several connection properties are available to influence the behavior of Fabric-aware connections. You can find the documentation for …

Hanging out in #mysql on freenode the other day, I overheard someone saying that the reason to use connection pools with MySQL is because JDBC connections are expensive to create. That is true out of the box, but mostly because the out of the box behavior of MySQL's JDBC driver is to be standards-compliant. If you know that your DBA and your developers aren't doing crazy things with the database (changing configurations without letting the developers know, going around the "standard" API calls to start/end transactions, etc), then you can get to the point where connection setup is no slower than any other API. Does this mean you shouldn't use a connection pool? NO! (more on this next week).

Here's an iterative overview of the changes made in configuration, and how they affect what queries the driver does on initialization.

First, asking the driver to connect with default configuration results in the following statements being …

If you're using Innodb and transactions with JDBC and your MySQL application, you should know about a couple of debugging features that made their way into MySQL Connector/J 5.1.15.

First, by adding "includeThreadNamesAsStatementComment=true" to your JDBC URL, you will get the current Java thread's name that is executing SQL on a given connection as a statement comment, visible in SHOW FULL PROCESSLIST output:

mysql> show full processlist;
+------+------+-----------------+------+---------+------+----------+------------------------------------------------------+
| Id   | User | Host            | db   | Command | Time | State    | Info                                                 |
+------+------+-----------------+------+---------+------+----------+------------------------------------------------------+
...                                        |
| 2939 | test | localhost:59339 | test | Query   |    5 | Updating | /* java …

With the release of MySQL Enterprise Monitor (MEM) 2.2, there is now the ability to monitor queries using the Query Analyzer (QUAN) without needing the agent proxy to be running. You can use a .NET or JDBC connector plugin to directly gather the query statistics. In the example below, we will use the MySQL Enterprise Plugin for Connector/J.

First, make sure both the Connector/J, the Connector/J plugin and the Apache Commons Logging jars are in the $CLASSPATH. At the time of writing, these are the files needed:

mysql-connector-java-5.1.12-bin.jar
c-java-mysql-enterprise-plugin-1.0.0.42.jar
required/commons-logging-1.1.1.jar

Then, add the plugin to the connection string so that it changes from something like this:

conn = …

What makes you think jdbc autoreconnect is needed?
Application is idle for long periods at a time?
Wait_timeout too short?
Network failure or glitches?

Some good suggestions form Mark Matthews - Bug #5020

Having encountered the problem again myself today, trying to make jdbc for mysql reconnect any terminated connections using autoreconnect=true I figured out a way to work it out from the pooling side.


Introduction to the problem:

On the mysql side wait_timeout is set to default 8hrs and any connections idle for longer than that were beomg terminated despite setting the connection string to: url=jdbc:mysql://localhost:3306/dbname?autoReconnect=true. The application was thence throwing an exception.

The solution was to introduce a ping from the pooler which for “Ibatis”, the pooler technology used …

Three great beta deliveries in one week!

MySQL Connector/.Net 6.0.2 beta, a new version of the all-managed .NET driver for MySQL.

MySQL Connector/C++ 1.0.4 beta, a new release providing  C++ API for connecting client applications to the MySQL Server. If you know JDBC, this should be familiar to you.

MySQL Connector/C 6.0.0 beta, a new version of the C API for accessing MySQL database servers

Use them and let us know what you think.

Learn more about Connector/C++ here.

Learn more about Connector/C …