Oracle 5.0 Reference Manual page 2138

(java.security.AccessControlException)
SQLState: 08S01
VendorError: 0
Either you're running an Applet, your MySQL server has been installed with the "skip-networking"
option set, or your MySQL server has a firewall sitting in front of it.
Applets can only make network connections back to the machine that runs the web server that served
the .class files for the applet. This means that MySQL must run on the same machine (or you must
have some sort of port re-direction) for this to work. This also means that you will not be able to test
applets from your local file system, you must always deploy them to a web server.
MySQL Connector/J can only communicate with MySQL using TCP/IP, as Java does not support Unix
domain sockets. TCP/IP communication with MySQL might be affected if MySQL was started with the
"skip-networking" flag, or if it is firewalled.
If MySQL has been started with the "skip-networking" option set (the Debian Linux package of MySQL
server does this for example), you need to comment it out in the file
my.cnf. Of course your
or anywhere else (depending on how MySQL was compiled for your system). Binaries created by us
always look in
/etc/my.cnf
will need to have the firewall configured to allow TCP/IP connections from the host where your Java
code is running to the MySQL server on the port that MySQL is listening to (by default, 3306).
21.3.15.4: I have a servlet/application that works fine for a day, and then stops working
overnight
MySQL closes connections after 8 hours of inactivity. You either need to use a connection pool that
handles stale connections or use the
Datasource Class Names, URL Syntax and Configuration Properties for
Also, catch
SQLExceptions
the way until your application exits. This is just good programming practice. MySQL Connector/J will
set the (see
SQLState
when it encounters network-connectivity issues during the processing of a query. Attempt to reconnect
to MySQL at this point.
The following (simplistic) example shows what code that can handle these exceptions might look like:
Example 20.12. Connector/J: Example of transaction with retry logic
public void doBusinessOp() throws SQLException {
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
//
// How many times do you want to retry the transaction
// (or at least _getting_ a connection)?
//
int retryCount = 5;
boolean transactionCompleted = false;
do {
try {
conn = getConnection(); // assume getting this from a
conn.setAutoCommit(false);
//
// Okay, at this point, the 'retry-ability' of the
// transaction really depends on your application logic,
// whether or not you're using autocommit (in this case
Troubleshooting Connector/J Applications
file might also exist in the
my.cnf
and datadir/my.cnf. If your MySQL server has been firewalled, you
autoReconnect
in your application and deal with them, rather than propagating them all
java.sql.SQLException.getSQLState()
// javax.sql.DataSource, or the
// java.sql.DriverManager
2118
/etc/mysql/my.cnf
directory of your MySQL server,
data
parameter (see Section 20.3.5.1, "Driver/
Connector/J").
in your API docs) to
or
/etc/
08S01