ColdFusion after a MariaDB upgrade: "Attempted reconnect 3 times. Giving up." with Connector/J 5.1 and the move to MariaDB Connector/J

After MariaDB moved from the 10.11 branch to a newer one, ColdFusion with a manually added MySQL Connector/J 5.1.44 stopped connecting: every query failed after 4 s with "Could not create connection to database server". The cause was the server's new version string, which made the driver switch on TLS in a version Java 21 blocks. One script moved every data source to MariaDB Connector/J.

Book an intro call ColdFusion and Lucee at Prownex

Connector/J 5.1.38 to 5.1.45: 0 connections to MariaDB 11.0 and later, 4 s to the error
Update from 10.11.3 to 10.11.19 on Debian 12: no difference for the driver
After a database restart 8 of 12 requests failed, with validation 0 of 12

Web application on Adobe ColdFusion 2025 (Java 21) with MariaDB on the same Debian 12 server and the MySQL Connector/J 5.1 driver

Challenge

An application on Adobe ColdFusion 2025 talked to MariaDB on the same server through several data sources of the type "Other". Someone had once copied the MySQL Connector/J 5.1.44 driver from 2017 into cfusion/lib by hand, as the Adobe knowledge base describes. For years nobody had to think about it.

After MariaDB moved from the 10.11 branch to a newer one, every page that read data waited 4 seconds and ended with the error "Could not create connection to database server. Attempted reconnect 3 times. Giving up." The database itself was running and the administrator could log in. The words "NonTransient" and "reconnect" pointed to the network, but the error came back on every attempt.

The constraints: the names of the data sources stay, because the CFML code uses them, the data has to look as it did before, and the application runs in production, so we check every change before switching over.

Solution

The cause sat in the server's version string. MariaDB 10.x announces itself with the compatibility prefix 5.5.5-, from 11.0.1 without it. Connector/J 5.1 therefore took the server for MySQL 5.7 or later, switched on TLS by itself and offered only TLSv1.1 and TLSv1, which Java 21 in ColdFusion 2025 has disabled. The connection failed on the application side before anything reached the database.

MariaDB Connector/J 3.5.11 in cfusion/lib replaced the old driver (as of 2026-11). One Admin API script moved every data source: type "Other", URL jdbc:mariadb://…?tinyInt1isBit=false, class org.mariadb.jdbc.Driver, the same names, users and passwords, with a check after each source. Connection validation with SELECT 1 came on top. Before handing over we checked queries, transactions, stored procedures, TINYINT(1) columns and zero dates.

Results

Connector/J 5.1.44 after the MariaDB branch change: 100 % of queries failed, 4.03 s to the error
After the move to MariaDB Connector/J 3.5: 7 of 7 sources with verifyDsn = YES, queries and transactions without errors
Connector/J 5.1 releases on MariaDB 11.8 and 13.0: 8 of 15 without a connection, 4 over TLS without verification, 3 unchanged
Update from 10.11.3 to 10.11.19 on Debian 12: No difference in the driver's behaviour
Errors after a database restart, 8 pooled connections: 8 of 12 without validation, 0 of 12 with "Validate connection"
TINYINT(1) after the move: 0, 1, 2 as before (without tinyInt1isBit=false: NO, YES, YES)

How we worked

ColdFusion's logs

application.log, exception.log with the full stack trace and coldfusion-error.log with the driver's messages. The last link of the exception chain pointed to TLS.
A JDBC probe outside ColdFusion

A small Java program on the same Java 21.0.10: it connects with the given driver, prints the server version and runs the application's typical queries, from reading Polish characters to a stored procedure.
The simplest hypothesis first

The update within Debian 12: the version from the bookworm release 1:10.11.3-1, the current 1:10.11.19-0+deb12u1 and a server updated in place with ColdFusion connected, with a service restart as in apt upgrade.
Newer MariaDB branches

11.4.13, 11.8.8, 12.3.3 and 13.0.2 from the vendor's builds and 11.8.6 from the Debian 13 package.
A driver matrix

MySQL Connector/J 5.0.8, 5.1.17, 5.1.27 and 15 releases from 5.1.34 to 5.1.49, MariaDB Connector/J 2.7.15, 3.5.10, 3.5.11 and 4.0.0.
The driver's code

The bytecode of the classes MysqlIO and ExportControlled from 5.1.45, 5.1.46 and 5.1.49 (javap -c), to confirm where TLS and the list of protocols come from.
Migration and differences in the data

The same queries and data types, TINYINT(1), BIT and zero dates, through the old and the new driver, inside ColdFusion and outside it.

Which driver connects to which MariaDB (Java 21, as of 2026-11)

Driver	MariaDB 10.11 from Debian 12, no TLS	MariaDB 11.4 to 13.0
MySQL Connector/J 5.0.8, 5.1.17, 5.1.34 to 5.1.37	Connects	Connects, without TLS
MySQL Connector/J 5.1.38 to 5.1.45	Connects	No connection: Communications link failure, caused by SSLHandshakeException: No appropriate protocol
MySQL Connector/J 5.1.46 to 5.1.49	Connects	Connects over TLS without certificate verification, a warning in the log on every connection
MariaDB Connector/J 3.5.11, jdbc:mariadb://	Connects	Connects
MariaDB Connector/J 3.5.11, old URL jdbc:mysql://	No suitable driver found for jdbc:mysql://… (only with permitMysqlScheme)	The same
MariaDB Connector/J 4.0.0, jdbc:mariadb://	Trying to connect with ssl, but ssl not enabled in the server	Connects
MariaDB Connector/J 4.0.0 with sslMode=disable	Connects	Connects

Challenges we overcame

The message in application.log described the last symptom, not the cause. Below are the log entries as ColdFusion wrote them; only the path of the CFML file and the thread name are generalised.

The exact log entries

application.log, on every request:

"Error","...-exec-6","11/02/26","17:40:29","","Error Executing Database Query.Could not create connection to database server. Attempted reconnect 3 times. Giving up. The specific sequence of files included or processed is: /app/wwwroot/katalog.cfm, line: 15 Could not create connection to database server. Attempted reconnect 3 times. Giving up."

exception.log, the full exception chain (JDK, Tomcat and ColdFusion filter frames left out and marked ...):

coldfusion.tagext.sql.QueryTag$DatabaseQueryException: Error Executing Database Query.
    at coldfusion.tagext.sql.QueryTag.startQueryExecution(QueryTag.java:853)
    at coldfusion.tagext.sql.QueryTag.doEndTag(QueryTag.java:750)
    ...
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
    ...
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.Util.getInstance(Util.java:408)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:918)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:897)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:886)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:860)
    at com.mysql.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:2097)
    at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2022)
    at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:779)
    at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
    ...
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:389)
    at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:330)
    at coldfusion.server.j2ee.sql.pool.JDBCPool.createPhysicalConnection(JDBCPool.java:614)
    at coldfusion.server.j2ee.sql.pool.ConnectionRunner$RunnableConnection.run(ConnectionRunner.java:59)
    ... 1 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1 milliseconds ago.  The last packet sent successfully to the server was 1 milliseconds ago.
    ...
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
    at com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(ExportControlled.java:203)
    at com.mysql.jdbc.MysqlIO.negotiateSSLConnection(MysqlIO.java:4901)
    at com.mysql.jdbc.MysqlIO.proceedHandshakeWithPluggableAuthentication(MysqlIO.java:1659)
    at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1226)
    at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2191)
    at com.mysql.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:2038)
    ... 12 more
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
    ...
    at com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(ExportControlled.java:188)
    ... 17 more

coldfusion-error.log, the driver's messages:

Mon Nov 02 17:40:25 CET 2026 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.
SQLException while attempting to connect: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up..

Not the update on Debian 12, but the 11.0 boundary

Between the packages 1:10.11.3-1 and 1:10.11.19-0+deb12u1 there is no difference for Connector/J 5.1: every driver version we checked behaved the same, also after the update in place. The driver sees both servers as MySQL 5.5.5-10.11…, and mariadb-upgrade does nothing after an update within the branch. What decides is the prefix 5.5.5-, which MariaDB dropped in 11.0.1 (MDEV-28910). Servers from 11.4 on also offer TLS without any configuration, with a certificate generated at startup.

The same "Connector/J 5" behaves in three ways

On MariaDB 11.0 and later the releases up to 5.1.37 connect without TLS, 5.1.38 to 5.1.45 do not connect at all, and 5.1.46 to 5.1.49 connect over TLS without certificate verification, writing a warning of several sentences to coldfusion-error.log for every new connection. Two servers with "the same" driver can therefore differ. We read the version in the jar's manifest (Implementation-Version: 5.1.44), not in the name of the folder.

The list of TLS protocols lives in the driver

In the releases 5.1.38 to 5.1.45 the class ExportControlled offers TLSv1.2 only to MySQL servers from 5.6 in the Enterprise edition. Every other server gets TLSv1.1,TLSv1. Java 21 lists both protocols in jdk.tls.disabledAlgorithms (in Oracle JDK since 11.0.11), so the handshake ends with "No appropriate protocol" before anything reaches the server. From 5.1.46 servers from 8.0.4 on get TLSv1.2 as well.

"NonTransient" and "reconnect" point to the network

ColdFusion opens the physical connection through connectWithRetries, even without autoReconnect=true in the URL. The driver tries three times, every request waits 4.03 s for the error, and under traffic ColdFusion's threads are mostly busy waiting. The real cause is the third Caused by in exception.log. Checking the firewall or the database's connection limit only costs time here.

The "MySQL" type in ColdFusion 2025 is a dead end

The "MySQL" type expects the class com.mysql.cj.jdbc.Driver, that is Connector/J 8 or later, which Adobe does not ship. Without that jar the data source returns "No suitable driver available for … The mysql package is not installed.", and cfpm.sh install mysql answers "mysql(2025.0.08.331874) package is already installed.", because the mysql package is the DataDirect driver. The right way is the type "Other", as in the Adobe knowledge base.

Swapping the jar is not enough, and the newest driver has other TLS defaults

MariaDB Connector/J 3.x and 4.x register only for jdbc:mariadb:; the old URL jdbc:mysql:// ends with "No suitable driver found", so every data source has to change. Version 4.0.0 from October 2026 needs Java 17 and defaults to sslMode=verify-full. Against the Debian 12 database without TLS it ends with:

java.sql.SQLNonTransientConnectionException: (conn=52) Trying to connect with ssl, but ssl not enabled in the server. TLS is enabled by default, set sslMode=disable to permit unencrypted connection

"Other" changes data types

The "MySQL" type appends tinyInt1isBit=false to the URL, "Other" does not. Without it both driver families return TINYINT(1) as Boolean, and ColdFusion shows the values 0, 1, 2 as NO, YES, YES. Connector/J 5.1 reported 0000-00-00 00:00:00 dates with the error "Value '0000-00-00 00:00:00' can not be represented as java.sql.Timestamp", MariaDB Connector/J returns an empty value. Code that relied on one or the other will behave differently.

Every database restart leaves dead connections in the pool

A package update restarts MariaDB, and ColdFusion keeps connections open. Each of them gives one error on first use: with 8 pooled connections, 8 of the next 12 requests failed, in both rounds. The same symptom after an ordinary update within 10.11 is easily taken for a driver failure:

"Error","...-exec-5","11/02/26","17:34:39","","Datasource shop verification failed.The root cause was that: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 31,181 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago. ..."
"Error","...-exec-1","11/02/26","17:34:39","","Error Executing Database Query.(conn=13) Socket error The specific sequence of files included or processed is: /app/wwwroot/katalog.cfm, line: 15 (conn=13) Socket error"

The first entry comes from Connector/J 5.1, the second from MariaDB Connector/J; its cause in exception.log is java.io.EOFException: unexpected end of stream, read 0 bytes from 4 (socket was closed by server). "Validate connection" with the query SELECT 1 removed these errors completely, 0 of 12.

Two rows of fifteen squares for the Connector/J releases from 5.1.34 to 5.1.49. Row MariaDB 10.11: all squares black. Row MariaDB 11.8: three black, eight orange outlines with a cross, four squares with a padlock under the bracket TLS

The move to MariaDB Connector/J step by step

The driver

MariaDB Connector/J 3.5.11 goes into cfusion/lib and the old jar goes away: two drivers that handle jdbc:mysql: in one folder are asking for trouble. Then a ColdFusion restart.

unzip -p cfusion/lib/mysql-connector-java-*.jar META-INF/MANIFEST.MF | grep Implementation-Version
cp mariadb-java-client-3.5.11.jar /opt/ColdFusion2025/cfusion/lib/
rm /opt/ColdFusion2025/cfusion/lib/mysql-connector-java-5.1.44.jar
systemctl restart <ColdFusion service>

We chose the 3.5 branch on purpose: it runs on any Java from 8, does not require TLS from a database on localhost and is maintained alongside 4.0 (as of 2026-11). On ColdFusion with Java 17 or 21, 4.0 is possible, but then with TLS on the database server or an explicit sslMode=disable for the local connection.

The data source in ColdFusion Administrator

Data & Services, Data Sources, driver "Other", the JDBC URL:

jdbc:mariadb://127.0.0.1:3306/<database>?tinyInt1isBit=false

The other fields:

Field	Value
CF Data Source Name	unchanged (the code uses it)
JDBC URL	the URL above
Driver Class	`org.mariadb.jdbc.Driver`
Driver Name	MariaDB Connector/J
User name, Password	unchanged
Maintain connections	on
Validate connection, Validation Query	on, `SELECT 1`

Every source with one script

The Admin API script runs once from localhost, first with run=0 as a preview, then with run=1. ColdFusion writes a copy neo-datasource.bak before saving; a copy of your own of neo-datasource.xml does no harm either.

<cfset createObject("component","CFIDE.adminapi.administrator").login(adminPassword="...", adminUserId="admin")>
<cfset dsApi = createObject("component","CFIDE.adminapi.datasource")>
<cfset all = dsApi.getDatasources()>
<cfloop collection="#all#" item="name">
  <cfset d = all[name]>
  <cfif NOT listFindNoCase("com.mysql.jdbc.Driver,com.mysql.cj.jdbc.Driver", d.class) AND d.driver NEQ "MySQL5">
    <cfcontinue>
  </cfif>
  <cfset newUrl = reReplace(reReplaceNoCase(d.url, "^jdbc:mysql:", "jdbc:mariadb:"), "[&?]$", "")>
  <cfif NOT findNoCase("tinyInt1isBit", newUrl)>
    <cfset newUrl &= (find("?", newUrl) ? "&" : "?") & "tinyInt1isBit=false">
  </cfif>
  <cfoutput>#name#: #d.url# -> #newUrl##chr(10)#</cfoutput>
  <cfif url.run EQ 1>
    <cfset dsApi.setOther(name=name, url=newUrl, class="org.mariadb.jdbc.Driver", driver="Other",
      username=d.username, password=d.password, encryptpassword=false,
      description=d.description, pooling=d.pooling, timeout=d.timeout, interval=d.interval,
      login_timeout=d.login_timeout, buffer=d.buffer, blob_buffer=d.blob_buffer,
      disable_clob=d.disable_clob, disable_blob=d.disable_blob, validationQuery=d.validationQuery,
      select=d.select, create=d.create, grant=d.grant, insert=d.insert, drop=d.drop, revoke=d.revoke,
      update=d.update, alter=d.alter, storedproc=d.storedproc, delete=d.delete)>
    <cfoutput>  verify: #dsApi.verifyDsn(dsn=name, returnMsgOnError=true)##chr(10)#</cfoutput>
  </cfif>
</cfloop>

The key is encryptpassword=false: getDatasources() returns the password already encrypted, so the script carries it over without knowing the database passwords, together with the source's SQL permissions and the CLOB and BLOB settings. Result: 7 sources moved, verify: YES for each. Connection validation is switched on in the Administrator or by the same setOther call with validateConnection=true, validationQuery="SELECT 1". We delete the script file from the server right after use, because it contains the administrator password.

Checks before handing over

Read queries, cftransaction with UPDATE, stored procedures, TINYINT(1) columns with the values 0, 1, 2 as before, and the places where the code checks zero dates. With procedures the difference turned out positive: Connector/J 5.1 reported "User does not have access to metadata required to determine stored procedure parameter types" for a procedure created by another user, MariaDB Connector/J needs no access to its body.

A workaround while the migration is prepared

If the move has to wait and the database is on the same server, Connector/J 5.1.38 to 5.1.45 connects to MariaDB 11.0 and later once useSSL=false is in the URL; enabledTLSProtocols=TLSv1.2 only works from 5.1.44. That is a workaround, not a fix: the driver has not been developed since 2021.

Before the next database update

mariadb -e "SELECT VERSION()"                      # 10.x or 11.x and later
apt-cache policy mariadb-server                    # where the package comes from and which version it moves to
grep -cE "Attempted reconnect|Communications link failure|NonTransientConnection" /opt/ColdFusion2025/cfusion/logs/exception.log
grep -c "Establishing SSL connection without" /opt/ColdFusion2025/cfusion/logs/coldfusion-error.log

A sheet labelled Admin API, from which an orange bus leads along seven even lanes to seven small databases, the label jdbc:mariadb above the lanes, a tick at each database

What we take from it

A JDBC driver added by hand is a dependency nobody remembers until the database changes branch. Connector/J 5.1 has not been developed since 2021 and was only waiting for the first change it would not survive. Findings like this are typical when we take over and maintain a system.
ColdFusion's message describes the last symptom, not the cause. Here the cause was the third Caused by, and the words "NonTransient" and "reconnect" led towards the network.
The move to MariaDB Connector/J is more than swapping a file. A different URL scheme, a different class, other TLS defaults in 4.0 and a different type mapping than the "MySQL" type. The Admin API script does it repeatably and checks right away.
Validating pooled connections costs one light query and removes the errors after every database restart, also after an ordinary security update.
We plan a database update together with the application. The database version before and after, the driver version from the jar's manifest and three phrases in ColdFusion's logs, not only in the database log.

The same pair of ColdFusion and MariaDB Connector/J under heavy load is shown in the JVM heap space project; the installation of ColdFusion 2025 Update 8 behind Apache is described in the ColdFusion 2025 project, and work on MariaDB itself in the SQL index project.

Your ColdFusion application stopped connecting to MariaDB after a database update, or your logs say "Attempted reconnect 3 times. Giving up."? We find the cause from the logs, move the data sources to a current driver without changing the code and check the data before and after. The first step is an intro call.

Sources

The information on versions and defaults comes from the vendors' publications (as of 2026-11):

Two rows of twelve squares for requests after a database restart. The upper row has no gate: the first eight squares are orange outlines with a cross, four are black. The lower row passes a gate labelled SELECT 1: all twelve squares black

Related situations

ColdFusion: end of support and options

According to Adobe, ColdFusion 2021 has received no security patches since 10 November 2025. We compare four routes: stay and harden, update, move to Lucee or replace the system step by step, with dates and risks (As of 2026-10).
Take over a legacy system without documentation

Your system runs, but nobody knows it in detail. We record application, database, server and email, assess the risks, recommend the next step in writing and, if you wish, take over operations.
Debian upgrade and CentOS replacement

Support for Debian 11 ended on 31 August 2026, and for CentOS 7 on 30 June 2024 (As of 2026-10). We will upgrade your server, or plan and carry out the move to Debian. We also work with Proxmox VE 8 and with physical servers that we move to Proxmox.

More projects

The MySQL backup was 751 bytes: one damaged MyISAM table and the restore test

For seven nights the cron backup script wrote a 751 B file instead of about 280 MB: one MyISAM table was marked as crashed, mysqldump stopped at LOCK TABLES, the script exited with code 0 and cron discarded the message. We reproduced the failure, repaired the table, moved the databases to InnoDB and introduced a backup that test-restores itself every night and raises an alarm.
A spam filter that ran but did not protect

Services up, configuration valid, no errors in the system status. Yet phishing landed in the inboxes while partners' newsletters went to spam. Our engineers measured which detection mechanisms actually fired, repaired the causes, and three months later found and fixed a regression that only showed up hour by hour.

In 20 minutes we work out which first step fits your system

You tell us the goal and the current state, and we say openly whether and how we can help. Reply within one working day, no obligation.

Book an intro call How we work

Phone (German, Polish, English) +48 501 250 220

Email Email

Reachable: Monday to Friday, 9:00 to 17:00 Central European Time; support and emergencies around the clock (24/7)

Challenge

Solution

Results

How we worked

ColdFusion's logs

A JDBC probe outside ColdFusion

The simplest hypothesis first

Newer MariaDB branches

A driver matrix

The driver's code

Migration and differences in the data