If a Java website is showing database connection errors, the cause is usually one of three areas: the database server is unreachable, the Java application is using the wrong connection settings, or the hosting account has hit a resource or permission limit. On a managed hosting platform with Plesk and a Java extension such as My App Server, these problems are often fixable without changing the application architecture.
For hosted Java and Tomcat applications, database connection errors can appear as startup failures, HTTP 500 errors, blank pages, JSP errors, stack traces in logs, or application timeouts. In many cases the issue is not the Java runtime itself, but the way the app server, database credentials, and network access are configured together.
Common reasons a Java website cannot connect to MySQL
When a Java website in the UK market reports a database connection problem, the most common causes are practical and configuration-related:
- Wrong database host name in the JDBC URL or application config.
- Incorrect username or password after a database change.
- Database user does not have access to the selected database.
- MySQL service is unavailable or temporarily overloaded.
- Connection limits are reached on the hosting account or database.
- Firewall, socket, or hostname resolution issues block access.
- Driver mismatch between the Java version and the MySQL connector.
- Connection pool misconfiguration in Tomcat or the application.
- Application points to localhost when a remote host is required, or the reverse.
- Database name, schema, or table access is wrong after a deployment.
In a managed hosting environment, you should first confirm whether the problem is local to one app or affects all sites using the same database service. That helps separate a Java application issue from a broader MySQL service issue.
How to identify the real error message
The exact error text matters. A generic “database connection failed” message is not enough to diagnose the issue. Check the application logs, Tomcat logs, and any Plesk or service logs available in the control panel.
Typical Java and MySQL error patterns
- Communications link failure usually points to host, port, network, or service availability.
- Access denied for user usually means bad credentials or missing permissions.
- Unknown database means the database name in the configuration is wrong or the database has not been created.
- Too many connections means the app is opening too many sessions or the limit is too low.
- Connection timed out can be a network issue, overloaded database, or wrong host value.
- Public Key Retrieval is not allowed may appear with some MySQL connector and authentication combinations.
If you use My App Server with Apache Tomcat, check both the web application logs and the service logs. A JDBC error can be thrown by the app at startup, during a request, or when the connection pool tries to open new sessions.
Check the database host, port, and JDBC URL
One of the most common causes is a mismatch in the JDBC connection string. Java applications usually connect through a JDBC URL such as a MySQL URL with a host, port, database name, and parameters.
What to verify
- The host name is correct and matches the hosting setup.
- The port is the one used by MySQL, usually 3306 unless your platform uses a different value.
- The database name is exact, including case sensitivity if relevant.
- The username is the database user, not the hosting panel login.
- The password is current and copied correctly.
- Any SSL or timezone parameters in the JDBC URL are suitable for the application.
If the application was moved from another environment, the connection string may still point to an old database server, a development host, or a staging database. That often happens after deploying a WAR file to Tomcat without updating external configuration values.
Confirm database user permissions in Plesk
In Plesk-based hosting, a database user must be assigned correctly to the database. Even if the credentials are valid, the application can still fail if the user has no rights to the schema.
Check the following
- The database exists under the correct subscription or hosting account.
- The database user is attached to that database.
- The user has sufficient privileges for the app’s queries.
- The application is not using a different database user from a copied config file.
For a Java website using My App Server, this is especially important after migrations or restores. A copied application may still have old credentials stored in a properties file, XML config, or environment variable.
Review Tomcat and Java application configuration
When Java hosting is managed through a private JVM or Apache Tomcat instance, the database connection may be configured in several places. The exact location depends on how the application was deployed.
Common configuration locations
- Application properties files
- Spring or framework configuration files
- Tomcat context descriptors
- Environment variables used by the app
- JNDI resources defined for the server
- Secrets or external config files loaded at runtime
If the app uses JNDI, verify that the resource name in the application matches the resource defined in Tomcat. If the app expects a direct JDBC connection, confirm the driver class and URL are consistent with the MySQL version in use.
Things that often break after deployment
- Hard-coded localhost values.
- Credentials stored in the wrong profile file.
- Different config used for production and test builds.
- Missing JDBC driver JAR after a manual upload.
- Old connection pool values copied from another server.
Because My App Server supports flexible Java hosting inside a shared hosting account, it is important to keep the application’s database settings separate from the server install logic. That makes troubleshooting much faster.
Check for connection pool and timeout problems
Modern Java applications usually use a connection pool instead of opening a new MySQL connection for every request. This improves performance, but it also means pool settings can cause database errors if they are not tuned correctly.
Common pool-related causes
- The pool size is too high for the database limits.
- Idle connections are closed by the database before the app reuses them.
- The validation query is wrong or too slow.
- Timeout values are too short for peak traffic.
- The application leaks connections and never returns them to the pool.
If errors happen only during busy periods, the database may be reachable but the app is exhausting available connections. In that case, review both application code and connection pool settings. For smaller Java hosting plans, keeping the pool lean and efficient is usually the best approach.
Make sure the MySQL service is available
Sometimes the issue is not the application at all. The MySQL service may be temporarily unavailable, restarting, overloaded, or applying maintenance tasks.
What to check in the hosting environment
- Whether other websites on the same account can connect to MySQL.
- Whether the database service responds from other tools or scripts.
- Whether recent changes were made to the service configuration.
- Whether there are signs of high load, disk issues, or limits being hit.
If a hosted Java application suddenly starts failing after working normally, compare the time of the first error with any recent changes in deployment, database maintenance, or account settings. That often narrows the cause quickly.
Test the database connection outside the application
A good troubleshooting step is to test the credentials and host from a simple script or database client. This helps determine whether the issue is in the Java app or in the database access itself.
Useful checks
- Try logging in with the same database user from a database tool.
- Run a small test query against the same database.
- Confirm the host resolves correctly from the hosting environment.
- Check whether the same credentials work in a separate test page or script.
If the simple test fails, the problem is likely at the credential, permission, or service level. If the test succeeds but the Java app fails, the issue is probably inside the application configuration, driver setup, or pool handling.
Check the MySQL driver and Java version compatibility
Java applications depend on the correct MySQL Connector/J driver. If the driver is too old or too new for the Java runtime and MySQL authentication method, the app may fail to connect even with correct credentials.
Watch for these compatibility issues
- Old connector versions with newer MySQL authentication settings.
- Driver JARs not included after a manual Tomcat deploy.
- Java version changes that require a different driver build.
- Applications compiled for one Java level but run on another.
With My App Server, one practical advantage is the ability to manage the Java version and service setup from the control panel. That makes it easier to align the runtime with the application’s requirements. For hosted JSP, servlet, and WAR deployments, this alignment is often crucial for stable database access.
Look for host or network restrictions
Some applications are configured to connect to MySQL through a host name that cannot be resolved correctly, or through a network path that is blocked. In hosted environments, this can happen after a migration or a config copy from a different server type.
Examples of host-related issues
- Using a local socket path when TCP is needed.
- Using an external database host that is not permitted from the hosting account.
- DNS resolving to an unexpected address.
- Connecting through the wrong IP after a server move.
For applications hosted under Plesk, always confirm whether the database is meant to be accessed locally within the same hosting account or remotely using a specific hostname and port. The right choice depends on your application setup.
Check limits and resource usage
In shared Java hosting, resource limits can affect database connectivity even when MySQL itself is healthy. If the app server is under load, it may create delayed connections or fail to initialize the pool.
Relevant limits to review
- CPU usage spikes during startup.
- Memory limits reached by the JVM.
- Process or thread limits.
- Connection limits to the database.
- Disk or I/O pressure affecting service response.
My App Server is designed for practical Java hosting and private JVM use inside a shared account, so it is sensible to keep database pools and application behavior within the assigned service limits. Heavy clustering or enterprise-scale failover design is outside that scope.
Step-by-step troubleshooting checklist
Use this sequence when a Java website shows database connection errors:
- Read the exact error message in the application or Tomcat logs.
- Verify the JDBC URL, host, port, database name, username, and password.
- Confirm the database user is assigned to the correct database in Plesk.
- Test the same credentials with a simple database login or query.
- Check whether the MySQL service is running and responsive.
- Review connection pool settings and timeout values.
- Make sure the JDBC driver matches the Java runtime and MySQL version.
- Inspect recent deployments for config changes or missing files.
- Check account limits, memory usage, and log entries around the failure time.
- Restart the Java service only after confirming the settings are correct.
If the issue remains, compare a working and failing environment side by side. In many cases the difference is a single character in the database name, an outdated password, or an incorrect host value.
Best practices for Java and MySQL on hosted platforms
To reduce recurring database errors, keep the configuration simple and explicit:
- Store database settings in one clear location.
- Avoid hard-coded credentials inside source files.
- Use a tested MySQL Connector/J version compatible with your Java runtime.
- Keep connection pool sizes modest for shared hosting.
- Monitor logs after every deployment.
- Update database passwords in all config layers when changes are made.
- Document which Tomcat service and Java version the app uses.
For hosted Java applications using My App Server, predictable configuration is more valuable than complex architecture. A well-managed Tomcat deployment with the correct database settings usually resolves these issues quickly.
When to contact support
Contact hosting support if you have checked the application settings and still cannot isolate the cause. Provide the exact error message, the time it started, the application name, and details of what was changed recently.
Useful information to include
- The full database error text.
- The Java/Tomcat version in use.
- Whether the app uses direct JDBC or JNDI.
- Whether the problem began after a deployment or password change.
- Whether other sites or scripts can connect to the same database.
This helps support determine whether the issue is related to the database service, the Plesk user mapping, the Tomcat service, or the application package itself.
FAQ
Why does my Java website work locally but fail on hosting?
Local and hosted environments often use different database host names, credentials, connector versions, or JVM settings. A config value that works on your workstation may not be valid in the hosted Tomcat environment.
Can a wrong Tomcat configuration cause MySQL errors?
Yes. If the JDBC resource, driver, or connection pool is misconfigured in Tomcat, the app may fail even when MySQL is healthy and the credentials are correct.
Why do I see “Access denied” even though the password is right?
That usually means the database user does not have permission for that database, the username is incorrect, or the app is connecting from a different host identity than expected.
Why do the errors appear only during busy hours?
This often points to connection pool exhaustion, too many simultaneous database sessions, or resource limits being hit on the hosting account or database service.
Do I need a dedicated enterprise application server for this?
Usually not for standard hosted Java, JSP, servlet, or small-to-medium Tomcat applications. In many cases, a private JVM with proper database configuration is enough.
Conclusion
Database connection errors in a Java website are usually caused by a configuration mismatch, permission issue, or resource limit rather than a deep application fault. In a Plesk-based hosting environment with My App Server, the fastest path is to check the JDBC settings, confirm the database user mapping, review Tomcat logs, and test the connection outside the application. Once the host, credentials, driver, and pool settings match the hosting setup, most MySQL connection errors can be resolved quickly and reliably.