When a Java website starts showing database connection errors, the problem is usually not the Java code alone. In a hosted environment, the error can come from the application settings, the MySQL server, the JDBC driver, the connection pool, the hosting limits, or even a temporary service issue in the control panel. For Java and Tomcat-based sites, the most important step is to identify whether the failure happens before the application reaches MySQL, or only when it tries to open a connection.
On a managed hosting platform with a control panel such as Plesk, Java applications often run inside a private JVM or Apache Tomcat instance through a service like My App Server. That makes deployment easier, but it also means the database connection depends on the app server configuration, the MySQL credentials, and the host-side limits of the account. This article explains the most common causes, how to check them, and what to fix first.
Common reasons a Java application cannot connect to MySQL
Database connection errors usually fall into one of these categories:
- Incorrect database hostname, port, username, password, or database name.
- The MySQL user does not have the required permissions.
- The JDBC URL is wrong or missing required parameters.
- The MySQL server is temporarily unavailable or overloaded.
- The Java app is using an outdated or incompatible JDBC driver.
- Connection pool settings are too aggressive or too small.
- The application has reached a hosting limit, such as memory, process, or connection limits.
- A firewall, DNS issue, or local network restriction is blocking access.
- The app server or Tomcat instance has not been restarted after a configuration change.
If your site works intermittently, the issue is often related to timeouts, expired idle connections, or pool exhaustion. If it fails immediately after deployment, the cause is more likely to be a bad connection string or wrong credentials.
What the error message usually means
Java database errors often look different, but the wording gives useful clues. A few common examples are:
- Access denied for user — the username, password, or grants are wrong.
- Communications link failure — the app cannot reach the MySQL server.
- Unknown database — the database name in the JDBC URL is incorrect, or the database was not created.
- Timeout waiting for connection from pool — the pool is exhausted or too small.
- Connection refused — MySQL is not listening on the expected host or port.
- No suitable driver — the JDBC driver is missing or incompatible.
- Public Key Retrieval is not allowed — the JDBC driver and MySQL authentication settings do not match.
Read the exact wording carefully. In Java hosting, the error text often points directly to the layer that needs attention.
Check the MySQL credentials first
The most common cause is still the simplest one: incorrect database login details. In a Plesk-based hosting account, verify the following:
- Database name
- Database username
- Password
- Host value in the JDBC URL
- Port number, usually 3306 unless your host specifies otherwise
If the application was migrated, redeployed, or restored from backup, credentials may no longer match the current database user. A small typo in the JDBC string can cause the entire application to fail.
Also check whether the database user has access to the correct database. In shared hosting, users are often created per database, and permissions are not automatically shared across all databases in the account.
Verify the JDBC URL and driver settings
Java applications connect to MySQL through a JDBC URL. If the URL is formatted incorrectly, the connection will fail even if the username and password are correct.
Typical things to review include:
- The host name or IP address used in the URL.
- The database name at the end of the connection string.
- Encoding and timezone options.
- SSL-related parameters if your database requires secure connections.
- Authentication settings required by your MySQL version.
For example, a Tomcat or Spring application may use a connection pool configured in a properties file, XML file, or environment variable. If the app was moved to a new hosting account, those values may still point to an old database host.
Also confirm that the JDBC driver is present in the application and matches the database version. A very old MySQL Connector/J version can produce errors with newer MySQL authentication methods.
Confirm that the database server is reachable
Even with correct credentials, the Java site cannot connect if the MySQL server is unreachable. This may happen for a short period during maintenance or service restarts, or because the app is trying to connect to the wrong host.
In a hosted environment, check the following:
- Is the MySQL service running?
- Is the host name correct for the account?
- Is the application using the local database host provided by the control panel?
- Is there any DNS issue if the database host is specified by name?
If the application is hosted on the same platform as the database, the local host setting is usually the right choice. If you are using a remote database, verify that remote access is enabled and that the database server accepts connections from your hosting account.
Review database user permissions
A user can exist, but still be blocked by missing privileges. This is especially important after migrations or manual database setup.
Make sure the MySQL user has permission to:
- Connect to the correct database
- Read tables used by the application
- Insert and update records if the site writes data
- Create or alter tables if the app performs schema updates
If the error appears only when the app performs a specific task, such as login or form submission, the database user may have read access but not write access. Review the grants in the hosting control panel or in the database management tool.
Check the Tomcat or My App Server configuration
In Java hosting platforms that provide a private JVM or Tomcat instance, the database connection can also fail because the application server has not loaded the updated configuration correctly.
For example:
- The app was deployed with the wrong context path.
- The datasource file was changed but the service was not restarted.
- The application still reads old environment values.
- The Tomcat instance is running a different Java version than expected.
If you manage Java hosting through a control panel extension such as My App Server, use the service controls to restart the Java service after changing database settings. In many cases, a restart clears stale connections and forces the app to load the updated configuration.
For private JVM hosting, it is also worth checking whether the app server has enough memory and whether startup completed without errors. A partially started service may appear online, but the database layer may not have initialized properly.
Understand connection pool problems
Connection pool settings are a frequent source of errors in hosted Java applications. A pool keeps database connections ready to use, which improves performance, but bad settings can create failures.
Typical pool-related issues include:
- Too many concurrent requests for too few database connections.
- Idle connections being closed by MySQL before the app reuses them.
- Long-running queries holding connections too long.
- Pool validation checks not matching the database server’s behavior.
If the application works for a while and then starts failing, you may be dealing with pool exhaustion or stale connections. In that case, increase the pool size carefully, shorten idle timeout values, or enable a validation query so the app tests connections before using them.
Do not increase pool size blindly. On shared hosting, too many simultaneous database connections can create load issues and make the app less stable.
Check hosting limits and resource usage
Managed Java hosting is designed to support small and medium applications, but it still has practical limits. If the application exceeds memory or resource limits, database connections may fail as a side effect.
Possible symptoms include:
- Random connection timeouts during traffic spikes
- Tomcat or the JVM restarting unexpectedly
- Slow page rendering before database errors appear
- Error logs showing memory pressure or process limits
Review the service usage and platform limits in the control panel. If your application has grown significantly, it may need configuration tuning, cleaner queries, or a more suitable hosting plan for the current workload.
Look at the application logs
The fastest way to diagnose a Java database error is to inspect the logs from both sides:
- Java application logs
- Tomcat logs
- MySQL error logs, if available
In a Plesk environment, the logs often show the real cause near the time of the failure. Look for:
- Authentication failures
- Connection timeout messages
- Driver class loading errors
- Datasource initialization failures
- SQL exceptions during startup
If the site uses a framework such as Spring, Hibernate, or a custom DAO layer, the first visible error may be only a wrapper. Scroll further down in the stack trace to find the original SQL exception.
Step-by-step troubleshooting checklist
Use this sequence to narrow down the problem quickly:
- Confirm the database name, username, and password.
- Verify the JDBC URL and port.
- Check that the MySQL user has access to the database.
- Test whether the database server is reachable.
- Confirm the correct JDBC driver is deployed.
- Restart the Java service or Tomcat instance after changes.
- Review logs for exact error wording.
- Check connection pool size and timeout settings.
- Review hosting limits, memory usage, and service health.
- Test the application again after each change.
This method avoids changing too many things at once and makes it easier to identify the true cause.
Examples of practical fixes
If the error says access denied
Reset the database password, update the application configuration, and verify that the user is assigned to the correct database. Then restart the app server so the new settings are loaded.
If the error says communications link failure
Check the host name in the JDBC URL, confirm that the MySQL service is running, and make sure the database host is reachable from the hosting account. If the site uses a remote database, confirm that remote access is allowed.
If the error appears after deployment
Compare the deployed configuration with the working local or staging configuration. In many cases, the issue is caused by an outdated properties file, missing environment variable, or incorrect datasource definition in Tomcat.
If the error happens only under load
Review connection pool limits, slow queries, and database usage. Too many concurrent requests can overwhelm a small pool or a lightly configured database server. Optimize the queries first, then tune the pool settings.
Best practices for Java and MySQL hosting
To reduce database connection problems over time, follow these practices:
- Store database settings in one clear configuration location.
- Use the correct JDBC driver for the MySQL version in use.
- Restart Tomcat or the Java service after connection changes.
- Keep connection pool settings conservative on shared hosting.
- Use validation queries if your application suffers from stale connections.
- Monitor logs regularly after deployments.
- Test database access after restoring backups or migrating the app.
- Keep the application and database schemas in sync.
In a hosting control panel environment, small configuration mistakes are easier to fix when you keep the app server settings, database details, and deployment files aligned.
When to contact hosting support
Contact support if you have already checked the credentials, JDBC URL, driver, and permissions, but the error still continues. A platform-side issue may be involved if:
- The MySQL service is unavailable from the control panel.
- The Java service does not start correctly.
- The problem affects multiple websites or databases.
- Log files show repeated service-level errors.
- The application works locally but not in the hosted environment, despite correct configuration.
When opening a support request, include the exact error message, the time it started, recent changes, and whether the problem happens on startup or only during certain actions. This helps the support team inspect the right service faster.
FAQ
Why does my Java site work locally but fail on the hosting server?
Local and hosted environments often use different database hosts, driver versions, credentials, or Java versions. The application may be correctly configured on your machine but still point to the wrong MySQL settings on the server.
Can a Tomcat restart fix database connection errors?
Yes, especially after changing the JDBC URL, password, or datasource settings. A restart forces the app server to reload the configuration and clear stale connections.
Why do I get database errors only after some time?
This often means connection pool exhaustion, idle connections being closed by MySQL, or a resource limit being reached. It may also indicate memory pressure or a slow query pattern.
Does the JDBC driver version matter?
Yes. An outdated driver can cause authentication, SSL, or compatibility issues with newer MySQL versions. Always use a driver version suitable for your database server.
What should I check first in Plesk?
Start with the database credentials, the database user permissions, and the service status for the Java app server. Then review logs and restart the service after any configuration change.
Conclusion
A Java website showing database connection errors is usually experiencing a configuration, permission, or service issue rather than a general application failure. In a managed hosting environment with My App Server, Tomcat, and MySQL, the most effective approach is to verify the database details, confirm the JDBC setup, check logs, and restart the Java service after changes. If the issue appears only under load, focus on the connection pool and hosting limits. If it appears immediately after deployment, the credentials or connection string are the most likely cause.
By checking each layer in order, you can resolve most Java and MySQL connection problems without unnecessary changes and get the application back online more quickly.