A primary reason for storing only the last two digits of years is to save on storage space, so perhaps YEAR(2) makes sense for big data or in situations where storage is constrained, right?  Well, no – the number of bytes used to store YEAR(2) data is the same as what is required when YEAR(4) is used:

mysql> SHOW CREATE TABLE y2\G
*************************** 1. row ***************************
Table: y2
Create Table: CREATE TABLE `y2` (
`y` year(2) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> SHOW CREATE TABLE y4\G
*************************** 1. row ***************************
Table: y4
Create Table: CREATE TABLE `y4` (
`y` year(4) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM y2;
+----------+
| COUNT(*) |
+----------+
| 33554432 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM y4;
+----------+
| COUNT(*) |
+----------+
| 33554432 |
+----------+
1 row in set (0.00 sec)

D:\mysql-5.5.20-win32\data\test>dir *.MYD
Volume in drive D is Data
Volume Serial Number is 4015-B2FF

Directory of D:\mysql-5.5.20-win32\data\test

04/25/2012  10:43 AM       234,881,024 y2.MYD
04/25/2012  10:45 AM       234,881,024 y4.MYD

Huh.

Well, that doesn’t make much sense, since YEAR(2) only stores the last two digits, while YEAR(4) stores all four – right?  Nope, YEAR(2) stores the full four digits, and has the same range of values as YEAR(4):

mysql> TRUNCATE y2;
Query OK, 0 rows affected (0.09 sec)

mysql> TRUNCATE y4;
Query OK, 0 rows affected (0.05 sec)

mysql> INSERT INTO y4 VALUES (1901), (2000), (2155);
Query OK, 3 rows affected (0.02 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y4 ORDER BY y;
+------+
| y    |
+------+
| 1901 |
| 2000 |
| 2155 |
+------+
3 rows in set (0.00 sec)

mysql> INSERT INTO y2 SELECT * FROM y4;
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2 ORDER BY y;
+------+
| y    |
+------+
|   01 |
|   00 |
|   55 |
+------+
3 rows in set (0.00 sec)

mysql> ALTER TABLE y2 MODIFY COLUMN y YEAR(4);
Query OK, 0 rows affected (0.13 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2 ORDER BY y;
+------+
| y    |
+------+
| 1901 |
| 2000 |
| 2155 |
+------+
3 rows in set (0.00 sec)

OK, so maybe one would use YEAR(2) because they really, really like the fun behavior that assumes that values 70-99 are 1970-1999, and values 01-69 are years 2001-2069:

mysql> TRUNCATE TABLE y2;
Query OK, 0 rows affected (0.02 sec)

mysql> ALTER TABLE y2 MODIFY COLUMN y YEAR(2);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> INSERT INTO y2 VALUES (69), (70);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2 ORDER BY y;
+------+
| y    |
+------+
|   70 |
|   69 |
+------+
2 rows in set (0.00 sec)

mysql> ALTER TABLE y2 MODIFY COLUMN y YEAR(4);
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2 ORDER BY y;
+------+
| y    |
+------+
| 1970 |
| 2069 |
+------+
2 rows in set (0.00 sec)

Except that behavior is identical to YEAR(4):

mysql> TRUNCATE TABLE y4;
Query OK, 0 rows affected (0.02 sec)

mysql> INSERT INTO y4 VALUES (69), (70);
Query OK, 2 rows affected (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y4 ORDER BY y;
+------+
| y    |
+------+
| 1970 |
| 2069 |
+------+
2 rows in set (0.00 sec)

There’s one area where behavior is different, and that’s in handling of the numeric value zero:

mysql> TRUNCATE TABLE y4;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO y4 VALUES (0);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM y4;
+------+
| y    |
+------+
| 0000 |
+------+
1 row in set (0.00 sec)

mysql> TRUNCATE TABLE y2;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO y2 VALUES (0);
Query OK, 1 row affected (0.01 sec)

mysql> SELECT * FROM y2;
+------+
| y    |
+------+
|   00 |
+------+
1 row in set (0.00 sec)

Looks the same so far, right?  Under the hood, though, it’s not:

mysql> ALTER TABLE y2 MODIFY COLUMN y YEAR(4);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2;
+------+
| y    |
+------+
| 2000 |
+------+
1 row in set (0.00 sec)

So a numeric zero inserted into a YEAR(2) column will be effectively stored as 2000, while the same value inserted into a YEAR(4) will be stored as “0000″ (invalid).  So, there’s one use case: When your application has to insert numeric zero values and have them stored as the year 2000.  Probably not terribly compelling.

Here’s one more not-so-compelling use case:  You really, really care about the number of bytes sent over the network, and only need the last two digits of a year.  As can be seen here, the number of bytes sent is lower for YEAR(2) data than YEAR(4) data – two bytes per row:

mysql> flush status;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from y2 limit 1;
+------+
| y    |
+------+
|   12 |
+------+
1 row in set (0.00 sec)

mysql> show session status like 'bytes_sent';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Bytes_sent    | 77    |
+---------------+-------+
1 row in set (0.00 sec)

mysql> flush status;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from y4 limit 1;
+------+
| y    |
+------+
| 2012 |
+------+
1 row in set (0.00 sec)

mysql> show session status like 'bytes_sent';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Bytes_sent    | 79    |
+---------------+-------+
1 row in set (0.00 sec)

But wait, if you can save bytes there, can you save bytes in other locations, like temporary tables created for sorting?  Nope – the full data is represented in the sort, otherwise this wouldn’t sort correctly:

mysql> INSERT INTO y2 VALUES (1969), (1970), (2000), (2071);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2 ORDER BY y;
+------+
| y    |
+------+
|   69 |
|   70 |
|   00 |
|   71 |
+------+
4 rows in set (0.00 sec)

There is some funky behavior related to equality matches, though:

mysql> SELECT y2.y y2, y4.y y4 FROM y2 LEFT JOIN y4 ON (y2.y = y4.y);
+------+------+
| y2   | y4   |
+------+------+
|   69 | NULL |
|   70 | 1970 |
|   00 | 2000 |
|   71 | NULL |
+------+------+
4 rows in set (0.00 sec)

mysql> SELECT * FROM y2 WHERE y = 1969 OR y = 2071;
+------+
| y    |
+------+
|   69 |
|   71 |
+------+
2 rows in set (0.00 sec)

mysql> ALTER TABLE y2 MODIFY COLUMN y YEAR(4);
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT y2.y y2, y4.y y4 FROM y2 LEFT JOIN y4 ON (y2.y = y4.y);
+------+------+
| y2   | y4   |
+------+------+
| 1969 | 1969 |
| 1970 | 1970 |
| 2000 | 2000 |
| 2071 | 2071 |
+------+------+
4 rows in set (0.00 sec)

Pretty strange, no?  I actually suspect this may be a bug and will report it as such.

So YEAR(2) really does have the same underlying data storage requirements as YEAR(4), and there’s no internal optimization for sorting or anything like that – in fact, the only areas where there might be optimization seem to produce bad results, as shown in the last example.  There’s extremely limited savings in terms of network overhead, and special handling of numeric zeros.  Since the MySQL server sends the results over the wire with just the last two years, that would be moderately helpful if that’s how your application needs to consume the data – but it also causes the following behavior, which is an absolute deal-breaker for me.  First, here’s the original table creation and data:

mysql> CREATE TABLE yd (y2 YEAR(2), y4 YEAR(4));
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO yd (y2) VALUES (1969), (1970), (2000), (2071);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> UPDATE yd SET y4 = y2;
Query OK, 4 rows affected (0.01 sec)
Rows matched: 4  Changed: 4  Warnings: 0

mysql> SELECT * FROM yd ORDER BY y2;
+------+------+
| y2   | y4   |
+------+------+
|   69 | 1969 |
|   70 | 1970 |
|   00 | 2000 |
|   71 | 2071 |
+------+------+
4 rows in set (0.00 sec)

Guess what happens when you recreate this from mysqldump?

D:\>mysql-5.5.20-win32\bin\mysqldump -uroot -P3307 --add-drop-table test yd | mysql-5.1.38-win32\bin\mysql -uroot -P3307 test

D:\>mysql-5.5.20-win32\bin\mysql -uroot -P3307 test -e"SELECT * FROM yd ORDER BY y2;"
+------+------+
| y2   | y4   |
+------+------+
|   70 | 1970 |
|   71 | 2071 |
|   00 | 2000 |
|   69 | 1969 |
+------+------+

Ouch.  That’s right, mysqldump produces 2-digit output, which – when replayed as an INSERT – prefixes the year with the centuries as described in the manual here.  The following demonstrates what’s really stored in the YEAR(2) columns after restoring using mysqldump:

mysql> UPDATE yd SET y4 = y2;
Query OK, 2 rows affected (0.00 sec)
Rows matched: 4  Changed: 2  Warnings: 0

mysql> SELECT * FROM yd ORDER BY y2;
+------+------+
| y2   | y4   |
+------+------+
|   70 | 1970 |
|   71 | 1971 |
|   00 | 2000 |
|   69 | 2069 |
+------+------+
4 rows in set (0.00 sec)

Nasty stuff, and reason enough for me to never touch YEAR(2).

Knowing the above, my challenge for you as a reader is to identify any compelling use case for YEAR(2).  Please feel free to offer suggestions as comments.

This release (and this feature, specifically) is also significant in at least one other way:  It’s the first release (and feature) of Connector/J authored by Alexander Soklakov – the newest member of the Connectors team and crack Java developer.  Like most things at MySQL, there was a good team backing Alex up (with Mark Matthews helping define the architecture, Rafal Somla coordinating the protocol-level changes, and Tonci Grgin overseeing it all).  Way to go, Alex and team!

Because the key MySQL 5.5 external authentication plugins are platform dependent (PAM, Windows), they may not be the best fit for Java users, where platform independence (and lack of reliance on native code) is a big priority.  We’re always interested to receive feature requests, though, so if you have an idea for how you would want to use MySQL external authentication in the context of your Java application, please let us know (comment here, or register the request at bugs.mysql.com).

The original purpose for writing this blog entry, however, was to supplement my previous entries on other Connector/J extension points.  Much to my chagrin, but your benefit, Alexander was way ahead of me.  The public docs haven’t quite caught up, but there’s great content in the CHANGES file.  He even includes example and test implementations.  I’ll just quote the CHANGES file directly:

  - Added support for pluggable authentication via the com.mysql.jdbc.AuthenticationPlugin
    interface (which extends standard "extension" interface). Examples are in
    com/mysql/jdbc/authentication and in testsuite.regression.ConnectionRegressionTest.
    This introduces three new properties:

       authenticationPlugins defines comma-delimited list of classes that implement
       com.mysql.jdbc.AuthenticationPlugin and which will be used for authentication
       unless disabled by "disabledAuthenticationPlugins" property.

       disabledAuthenticationPlugins defines comma-delimited list of classes implementing
       com.mysql.jdbc.AuthenticationPlugin or mechanisms, i.e. "mysql_native_password".
       The authentication plugins or mechanisms listed will not be used for authentication
       which will fail if it requires one of them. It is an error to disable the default
       authentication plugin (either the one named by "defaultAuthenticationPlugin" property
       or the hard-coded one if "defaultAuthenticationPlugin" propery is not set).

       defaultAuthenticationPlugin defines name of a class implementing
       com.mysql.jdbc.AuthenticationPlugin which will be used as the default authentication
       plugin. It is an error to use a class which is not listed in "authenticationPlugins"
       nor it is one of the built-in plugins. It is an error to set as default a plugin
       which was disabled with "disabledAuthenticationPlugins" property. It is an error
       to set this value to null or the empty string (i.e. there must be at least a valid
       default authentication plugin specified for the connection, meeting all constraints
       listed above).

It’s great work from Alexander, and I’m looking forward to his future work.  It also demonstrates the value of having a support organization with direct involvement in the development of all MySQL products, as this functionality was implemented in direct response to customer need.

Let us know if you have any problems implementing external authentication plugins, or have ideas on plugins you would find valuable for managing your Java deployments.

In my work, I frequently have to install specific version of MySQL Server or Cluster to validate behavior of a handful of commands, and MCM is a bit overkill.  I have a couple of tricks that I use to quickly set up MySQL Cluster on Windows environments:

1. I always use the .ZIP packages
2. I have a set cluster data directory (in my case, D:\cluster-data)
3. I have a standard Cluster configuration file (config.ini) that I use, with two data nodes, one management node, and two SQL nodes
4. I have a script I use to do some setup and start the necessary processes, after first making sure no other Cluster is running and there are no port conflicts for MySQL SQL nodes

The Cluster configuration file is very sparse:

[ndbd default]
NoOfReplicas=2
DataDir=D:\cluster-data

[NDB_MGMD]
HostName=127.0.0.1
NodeId=1
DataDir= D:\cluster-data
# Data Nodes
# One entry for each node
[NDBD]
HostName=127.0.0.1
NodeId=2
[NDBD]
HostName=127.0.0.1
NodeId=3
# SQL Nodes
# One entry for each node
[MYSQLD]
HostName=127.0.0.1
[MYSQLD]

If you use this configuration file, make sure that you also create the DataDir you specify – the Cluster management node will not start if it does not exist.

The batch file I use is similarly simple, but it saves me plenty of time when I have to quickly deploy a specific version for a quick 5-minute test:

REM stop MySQL SQL nodes running on ports 3307 or 3308, if any exist
REM (ignore errors if mysqld isn't available on the port)
bin\mysqladmin -uroot -P3307 shutdown
bin\mysqladmin -uroot -P3308 shutdown

REM stop MySQL data and management nodes, if running (connection failure errors can be ignored)
bin\ndb_mgm -e "shutdown"

REM start the MySQL Cluster management node
start bin\ndb_mgmd --configdir=%CD% -f config.ini

REM start the MySQL Cluster data nodes, passing --initial if the batch file received that argument
start bin\ndbd %1
start bin\ndbd %1

REM created a copy of the MySQL SQL node data directory, if it doesn't already exist
IF NOT EXIST %CD%\data2 XCOPY %CD%\data %CD%\data2 /i /S

REM start the MySQL SQL nodes on ports 3307 and 3308
start bin\mysqld --no-defaults --basedir=%CD% --datadir=%CD%\data --port=3307 --ndbcluster --ndb-connectstring=localhost:1186 --console
start bin\mysqld --no-defaults --basedir=%CD% --datadir=%CD%\data2 --port=3308 --ndbcluster --ndb-connectstring=localhost:1186 --console

The script expects to be run from within the directory created when unpacking the .ZIP file.  It leverages the default (blank) password for the root account in Windows .ZIP distributions to shutdown the SQL nodes, and uses port 3307 and 3308 to avoid causing problems with any existing MySQL server that may be running on port 3306 (which is my personal, persistent installation).

Hopefully this will help people looking to do a quick deployment of MySQL Cluster on Windows.

Unlike the previous extension points, my demo code does not contain examples of this.  In this case, though, there are some standard implementations provided with Connector/J that we can look at, instead.  The two implementations shipped with Connector/J today implement a “best response time” strategy and a “random” strategy.  The default behavior when using load-balanced deployments is “random”, and the Connector/J configuration properties documentation describes their use cases.  Below are the actual classes which define the behavior:

• com.mysql.jdbc.RandomBalanceStrategy
• com.mysql.jdbc.BestResponseTimeBalanceStrategy

These classes – and any user-implemented load-balancing strategy – implements the com.mysql.jdbc.BalanceStrategy interface.  As the purpose of this extension point is to define how load is balanced across MySQL instances, there’s really only one key method you need to focus on:  pickConnection().  The purpose of this method is to return a Connection (more specifically, a com.mysql.jdbc.ConnectionImpl object).  Looking at the RandomLoadBalacneStrategy code, you will see the logic that’s involved.

The first parameter to pickConnection() is a LoadBalancingConnectionProxy object.  This is the object that does much of the load-balancing work.  It also contains a few callback methods you will want to consider:

1. getGlobalBlacklist() – this method returns a Map<String, Long> of hosts that have been identified as unavailable.  The String key is the host/port, while the Long is the time that the blacklist entry should expire.  Inside the proxy, this global blacklist is defined as a static Map, meaning that Host X will be found in the blacklist by one Connection if another Connection object put it there after experiencing problems.  Access to the static variable is synchronized, and the Map returned from this method is a local copy.
2. shouldExceptionTriggerFailover() – this method takes a SQLException and determines whether such an Exception should trigger a failover.  This, too, is user-configurable, although the defaults are usually sufficient for most deployments.  A previous post contains detailed information on how to customize this behavior.
3. addToGlobalBlacklist() – this is the method you want to call if you want to add a host to the global blacklist.
4. createConnectionForHost() – this is a utility method that handles creation of a new ConnectionImpl object based on the host/port String, so that you don’t have to wire up ConnectionImpl objects directly.  If you look at the method implementation, you will see the work that goes into setting up a properly-configured ConnectionImpl.

The remaining parameters are, in order:

• List<String> – a list of configured hosts involved in load-balancing
• Map<String, ConnectionImpl> – a Map of “live” connections already established, accessed through the host/port key.  Thinking of this as a connection pool, these are the cached connections which can be reused if the host/port pair is chosen, instead of doing the additional work of setting up a new physical connection.
• long[] – an array of response times in the same order as the List<String> of configured hosts.  This is used in BestResponseTimeBalanceStrategy.
• int – number of retries that should be attempted before giving up on finding a new connection.

So, what can you do with this?  People frequently ask for a true round-robin load-balancer.  Our experience has been that RandomBalanceStrategy is far better, but if you really need a true round-robin load-balancing algorithm, you could implement it here.

• demo.connectorj.ExceptionInterceptorExample
• demo.connectork.plugins.ExampleExceptionInterceptor

To implement an exception interceptor, you need to do the following:

1. Create a Java class which implements com.mysql.jdbc.ExceptionInterceptor
2. Configure Connector/J to use your exception interceptor by passing the fully-qualified class name as the value for the “exceptionInterceptors” property.

Like statement interceptors, this extension point is stackable – you can create multiple exception interceptors, passing them in as a comma-delimited list of fully-qualified class names.  The exception interceptors are executed in order in which they are defined in the connection property.

The demo here simply demonstrates how this work, but doesn’t give much of an idea of the power behind this interface.  The demo code executes a command that’s not valid SQL syntax – which will trigger a server-side error – catches the normal exception, wraps it with some additional text in the message before returning it to the application (where it is hopefully logged).  So what can you do with this?

There are certain errors where diagnosis requires additional information about either connection or server state – at the time the exception is raised.  This gives you a hook to enable collection of this data.  For example, certain NDB (Cluster) errors map to the same MySQL Server error code and message, and you can get more information from the NDB problems by issuing SHOW WARNINGS immediately after the error.  Unless you want to recode your application, there’s a lot of value in the ability to add an ExceptionInterceptor which looks for such errors, executes the SHOW WARNINGS, takes the details returned and shoves them into the Exception message text.

Another example might be when you get a server error that indicates the connection character set is set to something other what it should be set to, based on the configuration settings, and you want to know what session character set or collation is in use.  Unless you change your application code, you can only assume what it should be – unless you implement an ExceptionInterceptor that collects that data when the problem is encountered and logs that information for you.

Generally speaking, this is an extension point that you probably won’t leverage for normal operations, but can be very useful for diagnosing Exceptions that are difficult to reproduce outside the context of your Java application deployment.  Because ExceptionInterceptors are only called when handling a SQLException thrown from Connector/J code, you don’t have to worry too much about performance penalties in production deployments.

• demo.connectorj.StatementInterceptorExample
• demo.connectork.plugins.ExampleStatementInterceptor

To implement a statement interceptor, you need to do the following:

1. Create a Java class which implements com.mysql.jdbc.StatementInterceptorV2
2. Configure Connector/J to use your statement interceptor by passing the fully-qualified class name as the value for the “statementInterceptors” property.

This extension point is stackable – you can create multiple statement interceptors, passing them in as a comma-delimited list of fully-qualified class names.

The example provided in the demo code is pretty bland, but illustrates what can be done.  In the demo code, we’ve implemented the preProcess() method to check for a certain trigger (“/* test */” in this case), which triggers entirely different behavior than what would normally transpire.  This code simply returns the result of  “SELECT NOW()” when triggered, instead of whatever would normally be executed on the server.  You’ll probably never need this particularly functionality, but there’s other interesting stuff you could do:

• Add memcached without changing a line of application code, by checking memcached before executing a query, and caching the results after retrieving non-cached data from MySQL.
• Work around MySQL server problem areas without changing application code.  Maybe you have slow-performing subqueries in an application you cannot change?  Use statement interceptors to rewrite them to more better-performing JOIN syntax equivalents.
• Perform some standard result set transformation by wrapping ResultSetInternalMethods returned object.
• Add fine-grained conditional audit logging or access control without changing application code.
• Track down problematic statements that you suspect may be issued by the application, but not logged anywhere else.
• Shard your data, and use statement interceptors to route statements to appropriate MySQL instances (or combine results fetched from multiple MySQL servers)  – again without changing application code.
• Implement low-overhead “ping” operation for connection pools that don’t allow you to define your own validation query.

There’s a lot that can be done with statement interceptors, and they are very easy to wire up – there’s really only five methods you need to implement:

• init()  – You can set up state variables here, if needed.  Returns void, so leaving this empty is fine.
• preProcess() – This is where you return a ResultSetInternalMethods object if you want to bypass the normal operation of the statement.  This is called before the statement is sent to the server, so you can change what is sent – or even bypass the sending – here.  If you return null, the driver executes the statement as it normally would.  If you return a non-null object, further execution is bypassed.  Note that the SQL String argument will be null for PreparedStatement objects; you’ll need to handle Statement and PreparedStatement executions differently in order to examine the SQL being sent.
• postProcess() – Like preProcess(), but invoked by the driver after the server has returned a result set.  This allows you to change the results returned or wrap them with some sort of custom decorator.
• executeTopLevelOnly() – Return true if you are issuing queries inside preProcess() or postProcess() that could cause infinite recursion.
• destroy() – Clean up any local references you created in init() here.

The demo code provided will give you a simple example of how to implement statement interceptors, but what you do with them is really limited only by your imagination.

The first major area I failed to cover in depth was really “Extension Points”, starting from slide #56.  There are four major extension points in Connector/J:

• Lifecycle Interceptors
• Statement Interceptors
• Exception Interceptors
• Loadbalancing Strategies

We’ll look at the first in this post.

Connection lifecycle events can be useful for instrumenting or debugging application database behavior, without changing application code.  In Connector/J, you can intercept the following lifecycle events by implementing com.mysql.jdbc.ConnectionLifecycleInterceptor:

• Connection creation (via the init() method)
• Connection.commit()
• Connection.rollback()
• Connection.setAutoCommit()
• Connection.close()
• Connection.setCatalog()
• Transaction start/end (via transactionBegun() and transactionCompleted() methods)
• Connection.close()
• Connection object destruction (via destroy() method)

So, how might this be useful?  In the demo code provided, I implemented code that prints the stack trace when Connection.rollback() is called.  Perhaps you are trying to understand where rollbacks are coming from in your application – the demo code lets you do just that.  The steps are fully illustrated in the demo code:

1. Create a lifecycle interceptor that implements com.mysql.jdbc.ConnectionLifecycleInterceptor.
2. Add logging in the rollback() method to track whatever you require.
3. Start the application and list the fully-qualified class name of the lifecycle interceptor you created in step #1 as the value for property, “connectionLifecycleInterceptors”.  In the demo code, this is found in demo.connectorj.LifecycleInterceptorExample at line 23:

props.setProperty(“connectionLifecycleInterceptors”, “demo.connectorj.plugins.ExampleLifecycleInterceptor”);

That’s it!

What other lifecycle events might you be interested in tracking?  Well, you might be interested in tracking the time between transaction start and end times.  You might be interested to know how many times setAutoCommit() is called.  It’s convenient that you can do all of this without modifying application code.

• presentation slides
  

• demo code

UPDATE:  I’ve started adding posts fleshing out the presentation materials, which I will index below:

• Extension points – lifecycle interceptors
• Extension points – statement interceptors
• Extension points – exception interceptors

Communications link failure – Last packet sent to the server was X ms ago.

Judging from the forums, many people have had problems with this.  Here’s a brief overview of the causes, and potential solutions.

Generally speaking, this error suggests that the network connection has been closed. There can be several root causes:

• Firewalls or routers may clamp down on idle connections (the MySQL client/server protocol doesn’t ping).
• The MySQL Server may be closing idle connections which exceed the wait_timeout or interactive_timeout threshold

There’s a couple of useful diagnostic details which can be useful.  For starters, when a recent (5.1.13) version of Connector/J is used, you should see additional details around both the last packet sent and received.  Older versions may simply indicate the last time a packet was sent to the server, which is frequently zero ms ago.  That’s not terribly useful, and it may be that you just sent a packet, but haven’t received a packet from the server for 12 hours.  Knowing how long it’s been since Connector/J last received a packet from the server is useful information, so if you are not seeing this in your exception message, update your driver.

The second useful diagnostic detail shows up when Connector/J notices that the time a packet was last sent/received exceeds the wait_timeout or interactive_timeout threshold.  It will attempt to notify you of this in the exception message.

The following can be helpful in avoiding such problems, but ultimately network connections can be volatile:

• Ensure connections are valid when checked out of connection pool (use query which starts with “/* ping */” *exactly* to execute lightweight ping instead of full query)
• Minimize duration a Connection object is left idle while other application logic is executed
• Explicitly validate Connection before using after being left idle for extended period of time
• Ensure wait_timeout and interactive_timeout are set sufficiently high
• Ensure tcpKeepalive is enabled
• Ensure that any configurable firewall or router timeout setting accounts for maximum expected idle connection time.
• Make sure that you are not setting socketTimeout, or that it is set to a sufficiently high value to avoid socket timeouts.

I’ve seen exception messages which indicate Connections being used after sitting idle for hours – sometimes days.  If you do this, make sure that you are explicitly testing the connection before using it after lengthy idle periods.  Network connections fail, and applications need to be prepared to handle that.  But expecting connections to survive extended periods where left idle and work magically when used again hours later is just asking for trouble.

I use Workbench for my daily work, and it’s a great tool.  If you haven’t tried the 5.2 release yet, you should.  While performing some maintenance, I happened to issue a DELETE statement against a table which had no indexes (it was 10 rows), and Workbench complained:

Error Code: 1175
You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column

It turns out this is a new feature in 5.2.26 (and is still there in 5.2.27) – Workbench now uses the equivalent of –safe-updates mode for the mysql command-line client (also known as the –i-am-a-dummy option – seriously).  This wasn’t exactly convenient for me, especially since the DELETE was part of a larger script which I then had to revise and step through manually after it failed, but there’s an easy way to change this behavior.  If you’re like me, you might consider disabling this:

• Go to Edit -> Preferences
• Select the SQL Editor tab
• Uncheck “Forbid UPDATE and DELETE statements without a WHERE clause (safe updates)”

Despite the text, the –safe-updates mode affects more than UPDATE and DELETE statements without WHERE clauses – it requires such statements to explicitly use indexes.

I’m changing this behavior on my installation before I run into other problems.

I’m no dummy.