Oracle 5.0 Reference Manual page 2142

• Firewalls or routers may clamp down on idle connections (the MySQL client/server protocol does not
ping).
• The MySQL Server may be closing idle connections that exceed the
interactive_timeout
To help troubleshoot these issues, the following tips can be used. If a recent (5.1.13+) version of
Connector/J is used, you will see an improved level of information compared to earlier versions. Older
versions simply display the last time a packet was sent to the server, which is frequently 0 ms ago.
This is of limited use, as it may be that a packet was just sent, while a packet from the server has
not been received for several hours. Knowing the period of time since Connector/J last received a
packet from the server is useful information, so if this is not displayed in your exception message, it is
recommended that you update Connector/J.
Further, if the time a packet was last sent/received exceeds the
interactive_timeout
Although network connections can be volatile, the following can be helpful in avoiding problems:
• Ensure connections are valid when used from the connection pool. Use a query that starts with
to execute a lightweight ping instead of full query. Note, the syntax of the ping needs to be
ping */
exactly as specified here.
• Minimize the duration a connection object is left idle while other application logic is executed.
• Explicitly validate the connection before using it if the connection has been left idle for an extended
period of time.
• Ensure that
wait_timeout
• Ensure that
tcpKeepalive
• Ensure that any configurable firewall or router timeout settings allow for the maximum expected
connection idle time.
Note
Do not expect to be able to reuse a connection without problems, if it has being
lying idle for a period. If a connection is to be reused after being idle for any
length of time, ensure that you explicitly test it before reusing it.
21.3.15.13: Why does Connector/J not reconnect to MySQL and re-issue the statement
after a communication failure, instead of throwing an Exception, even though I use the
connection string option?
autoReconnect
There are several reasons for this. The first is transactional integrity. The MySQL Reference Manual
states that "there is no safe method of reconnecting to the MySQL server without risking some
corruption of the connection state or database state information". Consider the following series of
statements for example:
conn.createStatement().execute(
"UPDATE checking_account SET balance = balance - 1000.00 WHERE customer='Smith'");
conn.createStatement().execute(
"UPDATE savings_account SET balance = balance + 1000.00 WHERE customer='Smith'");
conn.commit();
Consider the case where the connection to the server fails after the
If no exception is thrown, and the application never learns about the problem, it will continue executing.
However, the server did not commit the first transaction in this case, so that will get rolled back. But
execution continues with the next transaction, and increases the
The application did not receive an exception, so it continued regardless, eventually committing the
Troubleshooting Connector/J Applications
threshold.
threshold, this is noted in the exception message.
and
interactive_timeout
is enabled.
2122
wait_timeout
or
wait_timeout
are set sufficiently high.
to checking_account.
UPDATE
savings_account
or
/*
balance by 1000.