Tomcat website database connection errors usually mean that the application cannot reach MySQL, MariaDB, or another database service with the credentials, network path, or connection settings it expects. In a hosted Tomcat environment, the cause is often not the Java code itself, but a mismatch between the app configuration and the hosting setup: wrong database hostname, inactive service, changed password, missing JDBC driver, too many open connections, or a connection pool that is not tuned for the available limits.
If your site runs on a managed hosting platform with a control panel such as Plesk and a private Tomcat or JVM instance, the troubleshooting process is usually straightforward. You need to verify the database service status, confirm the connection details in the application configuration, check the Tomcat logs, and make sure the JDBC driver and pooling settings match the database version and hosting environment.
Common reasons a Tomcat site shows database connection errors
Database connection problems in Tomcat can appear as HTTP 500 errors, blank pages, login failures, timeouts, or stack traces such as Communications link failure, Access denied, Connection refused, or Cannot create PoolableConnectionFactory. The exact message matters because it points to the layer that is failing.
1. Incorrect database host, name, username, or password
This is the most common cause. A Tomcat application typically reads database settings from a properties file, environment variables, JNDI resource, or framework configuration. If any value is wrong, the app cannot open a connection.
Typical examples:
- The database name was changed after deployment.
- The password was updated in the control panel but not in the application config.
- The application is still trying to connect to
localhostwhen it should use a specific database hostname. - A typo exists in the JDBC URL.
2. The database service is unavailable
Even if the configuration is correct, the database server itself may be stopped, overloaded, or temporarily unreachable. In shared hosting environments, this may happen during maintenance, resource pressure, or a service restart. The application will then fail to obtain a connection until the service is available again.
3. The JDBC driver is missing or incompatible
Tomcat needs the correct JDBC driver for the database engine and version you are using. If the driver JAR is missing from the application’s WEB-INF/lib directory, or if it is not compatible with the Java version in use, connection creation can fail.
This is especially relevant when you run a private JVM through My App Server, because the Java version is selectable and some older drivers do not work well with newer JVM releases.
4. Connection pool limits are too low or too high
Many Tomcat applications use a connection pool. If the pool is too small, the site may show database errors during traffic spikes. If it is too large, it may exceed the hosting account limits or the database server’s max connections setting.
Common signs include:
- Errors appear only under load.
- The site works after a restart, then fails again later.
- Requests queue up while waiting for a free connection.
5. Firewall, host restriction, or remote access rule is blocking the connection
If your application connects to a remote database, network access can be blocked by firewall rules, host-based restrictions, or a database account that is not allowed to connect from the application host. In hosted setups, this often happens when the database hostname, allowed IP, or access policy is not aligned with the application.
6. SSL or protocol mismatch
Some MySQL and MariaDB setups require SSL, while others do not. If the JDBC URL includes SSL options that the database does not support, or if SSL is required but not configured, the connection can fail. Protocol mismatches can also occur when an older application tries to talk to a newer database version without the right driver settings.
7. Timeouts and stale connections
Tomcat may keep connections open in a pool. If the database drops idle connections or the hosting environment recycles services, the application may try to reuse a stale connection and fail. This often shows up after periods of inactivity or after the database restarts.
How to identify the real cause in Tomcat
Before changing settings, check the error message and logs. In a managed hosting environment, this is the fastest way to locate the source of the problem.
Check the Tomcat application logs
Review the Tomcat logs for stack traces and the exact database error. Look for:
SQLExceptionJDBCConnectionExceptionCommunications link failureAccess denied for userUnknown databaseCannot create PoolableConnectionFactory
The message usually tells you whether the issue is authentication, hostname resolution, network access, or a service timeout.
Check whether the database opens from another client
If you can access the database with a database tool or command line client using the same credentials, the account may be valid and the issue may be in Tomcat, the JDBC URL, or the driver. If the database cannot be reached from anywhere, the service, password, or access policy is the likely cause.
Confirm the app’s connection settings
Check the location where your application stores database settings. Depending on the application, this may be:
context.xmlserver.xmlweb.xml- framework properties files
- environment configuration in the control panel
Make sure the JDBC URL, username, password, and driver class match the current database details.
Verify Java and JDBC compatibility
When using a custom Tomcat or private JVM, confirm that the selected Java version is compatible with the application and JDBC driver. A driver that works on Java 8 may not be the best choice for Java 17, and vice versa. If the app uses a newer database server, an older driver may not negotiate the connection correctly.
Practical troubleshooting steps
Follow these steps in order. They cover most database connection problems for Tomcat-hosted applications.
Step 1: Restart the application service
If your hosting platform provides service control through Plesk or My App Server, restart the Tomcat service or the private JVM instance first. This clears stale connections and reloads configuration files. If the problem was caused by a temporary failure, the site may recover immediately.
Step 2: Verify the database credentials
Open the application’s database configuration and compare it with the current database settings in the control panel. Check:
- database name
- username
- password
- host or server address
- port number
Even a single character difference can cause an authentication failure.
Step 3: Test the JDBC URL
For MySQL or MariaDB, the connection string should be valid for your database and driver version. A common pattern looks like this:
jdbc:mysql://hostname:3306/database_name
In some cases, additional parameters are needed for timezone handling, Unicode, SSL, or connection timeout behavior. Keep the URL as simple as possible during troubleshooting, then add options only if the application needs them.
Step 4: Confirm the JDBC driver is installed
Make sure the correct driver JAR file is included in the application package or the Tomcat library path used by your hosting setup. If you deployed a WAR file, the driver may need to be inside the application bundle unless your hosting provider documents a shared library location.
If you recently updated Java through My App Server, recheck driver compatibility after the upgrade.
Step 5: Review connection pool settings
If the application uses a pool such as Apache DBCP, HikariCP, or a built-in Tomcat datasource, confirm the values are suitable for a hosted account. Useful settings to review include:
- maximum active connections
- minimum idle connections
- validation query
- max wait time
- idle timeout
- test on borrow or test while idle
For small and medium hosted applications, conservative pool sizing is usually better than large values that can exhaust shared resources.
Step 6: Check the database service and access rules
If the database is separate from the application, confirm that remote access is allowed and that the hostname resolves correctly. If the database is local to the hosting account, make sure the service is active and reachable from the Tomcat instance.
If your provider uses a control panel, verify that the database user has privileges for the relevant schema and that host restrictions allow connections from the application environment.
Step 7: Look for time-based failures
If the site works after restart but fails later, stale connections may be the issue. Set up connection validation so that Tomcat checks a connection before handing it to the app. This is often more reliable than leaving idle connections unchecked.
Tomcat-specific settings that often help
When a Tomcat website shows database errors, the application may need better datasource configuration rather than code changes. In a hosted Tomcat setup, these settings are often enough to stabilize the site.
Use a validation query
A validation query helps the pool confirm that a connection is still alive. For MySQL and MariaDB, a simple query such as SELECT 1 is often used.
Enable stale connection checks
If supported by your pool, enable test-on-borrow or equivalent validation so the app does not reuse a dead connection. This is useful when the database or Tomcat service restarts periodically.
Set realistic pool sizes
A hosted application usually does not need a very large pool. Start with modest values and increase only if the application demonstrates a real need. Too many open connections can create pressure on both the application and the database service.
Match the Java version with the application
My App Server lets you choose a Java version and manage your own Tomcat or private JVM from the control panel. If an application was written for a specific Java release, use that version where possible. A mismatch can produce indirect database problems, especially when the JDBC driver or persistence layer changes behavior across Java versions.
How My App Server fits into troubleshooting
For Tomcat hosting, My App Server gives you practical control over the runtime without turning the setup into a complex enterprise platform. This is useful when you need to diagnose a database issue quickly.
- You can run a private JVM and separate it from other hosted apps.
- You can choose from ready-to-install Java and Tomcat versions.
- You can deploy WAR, JSP, and servlet applications more easily.
- You can restart or manage the service from the control panel.
- You can adjust the runtime version if a driver or application requires it.
This makes it easier to isolate whether the problem is in the app, the Tomcat configuration, the Java runtime, or the database connection settings. For small and medium Java applications, that level of control is often enough to fix the issue without moving to a more complicated architecture.
Example scenarios
Scenario 1: Access denied after a password change
A developer updates the database password in the control panel but forgets to update the application’s properties file. Tomcat starts normally, but the app logs show Access denied for user. The fix is to update the stored password in the app configuration and restart the service.
Scenario 2: Works locally, fails on the hosted server
The app connects successfully on a local workstation but fails on the hosted Tomcat instance. The cause is often a different JDBC driver version, an incorrect database hostname, or missing remote access permission. Checking the Tomcat logs and the exact JDBC URL usually reveals the difference.
Scenario 3: Site fails only during busy periods
The application works most of the day, but database errors appear during peak traffic. This usually points to connection pool exhaustion, slow queries, or too many simultaneous requests for the hosting limits. Reducing the pool size slightly, adding validation, or optimizing queries may solve it.
Scenario 4: Random failures after idle time
The site works after a restart and then fails after being idle overnight. This often indicates stale pooled connections or a database service that closes idle sessions. Enable validation and test the connection before reuse.
Best practices for hosted Tomcat applications
To reduce database connection errors in a Tomcat hosting environment, follow these practices:
- Keep database credentials synchronized between the control panel and the application config.
- Use the correct JDBC driver for the selected Java version.
- Prefer simple, validated connection settings over complex tuning at the start.
- Set sensible connection pool limits for a shared hosting account.
- Enable connection validation if idle disconnects are common.
- Check logs first before making broad configuration changes.
- Restart the Tomcat service after any database or config update.
For applications deployed through a Plesk-based Java hosting solution, these practices are especially helpful because they align with the way service control, version selection, and deployment usually work in a managed environment.
FAQ
Why does Tomcat show database errors even though the database exists?
Because the application may still be using the wrong credentials, hostname, JDBC driver, or connection pool settings. The database can exist and still reject the connection.
What does Communications link failure usually mean?
It typically means Tomcat cannot reach the database server over the network, the service is down, or the connection was dropped before the app could complete the handshake.
Should I put the JDBC driver inside the WAR file?
Often yes, unless your hosting provider documents a shared library location. Packaging the correct driver with the application can avoid version conflicts.
Why does the site work after restarting Tomcat?
A restart clears stale pooled connections and reloads configuration. If the site fails again later, the problem is likely related to connection pooling, timeouts, or a database service interruption.
Can a Java version change cause database connection problems?
Yes. A new Java version can expose compatibility issues in the JDBC driver or the framework layer. When using a private JVM, verify that the app, driver, and Java release are compatible.
What is the fastest first check?
Start with the error message in the logs, then confirm the database username, password, and host. In most cases, those two checks identify the issue quickly.
Conclusion
When a Tomcat website shows database connection errors in the UK market, the root cause is usually a mismatch between the application configuration and the hosted database environment rather than a problem with Tomcat itself. The most effective approach is to inspect the logs, verify credentials and JDBC settings, confirm driver compatibility, and check connection pooling behavior.
In a managed hosting setup with Plesk and My App Server, you have the practical tools needed to resolve most issues: service control, Java version selection, private Tomcat or JVM management, and a clean deployment path for WAR, JSP, and servlet applications. With the right configuration, small and medium Java sites can run reliably without unnecessary complexity.