ColdFusion nach dem MariaDB-Update: „Attempted reconnect 3 times. Giving up.“ mit Connector/J 5.1 und der Wechsel zu MariaDB Connector/J

Nach dem Wechsel von MariaDB 10.11 auf einen neueren Zweig verband sich ColdFusion mit dem von Hand eingespielten MySQL Connector/J 5.1.44 nicht mehr: Jede Abfrage endete nach 4 s mit „Could not create connection to database server“. Schuld war die neue Versionskennung des Servers, wegen der der Treiber TLS in einer Version einschaltete, die Java 21 sperrt. Ein Skript stellte alle Datenquellen um.

Erstgespräch vereinbaren ColdFusion und Lucee bei Prownex

Connector/J 5.1.38 bis 5.1.45: 0 Verbindungen zu MariaDB ab 11.0, 4 s bis zum Fehler
Update von 10.11.3 auf 10.11.19 unter Debian 12: kein Unterschied für den Treiber
Datenbankneustart: 8 von 12 Anfragen mit Fehler, mit Validierung 0 von 12

Webanwendung auf Adobe ColdFusion 2025 (Java 21) mit MariaDB auf demselben Server unter Debian 12 und dem Treiber MySQL Connector/J 5.1

Ausgangslage

Eine Anwendung auf Adobe ColdFusion 2025 sprach über mehrere Datenquellen vom Typ „Other“ mit einer MariaDB auf demselben Server. Den Treiber MySQL Connector/J 5.1.44 aus dem Jahr 2017 hatte jemand irgendwann von Hand nach cfusion/lib kopiert, so wie es die Wissensdatenbank von Adobe beschreibt. Jahrelang musste niemand an ihn denken.

Nach dem Wechsel von MariaDB 10.11 auf einen neueren Zweig wartete jede Seite, die Daten las, 4 Sekunden und endete mit dem Fehler „Could not create connection to database server. Attempted reconnect 3 times. Giving up.“ Die Datenbank selbst lief, der Administrator meldete sich ohne Probleme an. Die Wörter „NonTransient“ und „reconnect“ deuteten auf das Netzwerk, aber der Fehler kam bei jedem Versuch.

Die Randbedingungen: Die Namen der Datenquellen bleiben, weil der CFML-Code sie verwendet, die Daten sollen aussehen wie vor der Änderung, und die Anwendung läuft produktiv, also prüfen wir jede Änderung vor dem Umschalten.

Lösung

Die Ursache steckte in der Versionskennung des Servers. MariaDB 10.x meldet sich mit dem Kompatibilitätspräfix 5.5.5-, ab 11.0.1 ohne. Connector/J 5.1 hielt den Server deshalb für MySQL ab 5.7, schaltete selbst TLS ein und bot nur TLSv1.1 und TLSv1 an, die Java 21 in ColdFusion 2025 deaktiviert hat. Die Verbindung scheiterte auf der Seite der Anwendung, bevor irgendetwas die Datenbank erreichte.

Den alten Treiber ersetzte MariaDB Connector/J 3.5.11 in cfusion/lib (Stand 2026-11). Ein Skript über die Admin API stellte alle Datenquellen um: Typ „Other“, Adresse jdbc:mariadb://…?tinyInt1isBit=false, Klasse org.mariadb.jdbc.Driver, dieselben Namen, Benutzer und Passwörter, nach jeder Quelle eine Prüfung. Dazu kam die Validierung der Verbindungen mit SELECT 1. Vor der Übergabe haben wir Abfragen, Transaktionen, gespeicherte Prozeduren, TINYINT(1)-Spalten und Nulldaten geprüft.

Ergebnisse

Connector/J 5.1.44 nach dem Zweigwechsel von MariaDB: 100 % der Abfragen mit Fehler, 4,03 s bis zum Fehler
Nach dem Wechsel zu MariaDB Connector/J 3.5: 7 von 7 Quellen mit verifyDsn = YES, Abfragen und Transaktionen fehlerfrei
Versionen von Connector/J 5.1 auf MariaDB 11.8 und 13.0: 8 von 15 ohne Verbindung, 4 über TLS ohne Prüfung, 3 unverändert
Update von 10.11.3 auf 10.11.19 unter Debian 12: Kein Unterschied im Verhalten des Treibers
Fehler nach einem Datenbankneustart, 8 Verbindungen im Pool: 8 von 12 ohne Validierung, 0 von 12 mit „Validate connection“
TINYINT(1) nach der Umstellung: 0, 1, 2 wie vor der Änderung (ohne tinyInt1isBit=false: NO, YES, YES)

So sind wir vorgegangen

Die Logs von ColdFusion

application.log, exception.log mit dem vollständigen Stacktrace und coldfusion-error.log mit den Meldungen des Treibers. Das letzte Glied der Ausnahmekette zeigte auf TLS.
Eine JDBC-Sonde außerhalb von ColdFusion

Ein kleines Java-Programm mit derselben Java 21.0.10: verbindet sich mit dem angegebenen Treiber, gibt die Serverversion aus und führt typische Abfragen der Anwendung aus, vom Lesen mit polnischen Zeichen bis zur gespeicherten Prozedur.
Zuerst die einfachste Hypothese

Das Update innerhalb von Debian 12: die Version aus dem Release bookworm 1:10.11.3-1, die aktuelle 1:10.11.19-0+deb12u1 und ein an Ort und Stelle aktualisierter Server mit angeschlossenem ColdFusion, mit Neustart des Dienstes wie bei apt upgrade.
Neuere Zweige von MariaDB

11.4.13, 11.8.8, 12.3.3 und 13.0.2 aus den Builds des Herstellers sowie 11.8.6 aus dem Paket von Debian 13.
Eine Matrix der Treiber

MySQL Connector/J 5.0.8, 5.1.17, 5.1.27 und 15 Releases von 5.1.34 bis 5.1.49, MariaDB Connector/J 2.7.15, 3.5.10, 3.5.11 und 4.0.0.
Der Code des Treibers

Der Bytecode der Klassen MysqlIO und ExportControlled aus 5.1.45, 5.1.46 und 5.1.49 (javap -c), um zu bestätigen, woher TLS und die Liste der Protokolle kommen.
Umstellung und Unterschiede in den Daten

Dieselben Abfragen und Datentypen, TINYINT(1), BIT und Nulldaten, über den alten und den neuen Treiber, in ColdFusion und außerhalb.

Welcher Treiber sich mit welcher MariaDB verbindet (Java 21, Stand 2026-11)

Treiber	MariaDB 10.11 aus Debian 12, ohne TLS	MariaDB 11.4 bis 13.0
MySQL Connector/J 5.0.8, 5.1.17, 5.1.34 bis 5.1.37	Verbindet sich	Verbindet sich, ohne TLS
MySQL Connector/J 5.1.38 bis 5.1.45	Verbindet sich	Keine Verbindung: Communications link failure, Ursache SSLHandshakeException: No appropriate protocol
MySQL Connector/J 5.1.46 bis 5.1.49	Verbindet sich	Verbindet sich über TLS ohne Zertifikatsprüfung, Warnung im Log bei jeder Verbindung
MariaDB Connector/J 3.5.11, jdbc:mariadb://	Verbindet sich	Verbindet sich
MariaDB Connector/J 3.5.11, alte Adresse jdbc:mysql://	No suitable driver found for jdbc:mysql://… (erst mit permitMysqlScheme)	Ebenso
MariaDB Connector/J 4.0.0, jdbc:mariadb://	Trying to connect with ssl, but ssl not enabled in the server	Verbindet sich
MariaDB Connector/J 4.0.0 mit sslMode=disable	Verbindet sich	Verbindet sich

Herausforderungen, die wir gelöst haben

Die Meldung im application.log beschrieb das letzte Symptom, nicht die Ursache. Unten stehen die Logeinträge so, wie ColdFusion sie geschrieben hat; verallgemeinert sind nur der Pfad der CFML-Datei und der Threadname.

Die genauen Logeinträge

application.log, bei jeder Anfrage:

"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, die vollständige Ausnahmekette (Frames von JDK, Tomcat und den ColdFusion-Filtern ausgelassen und mit ... markiert):

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, die Meldungen des Treibers:

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..

Nicht das Update unter Debian 12, sondern die Grenze 11.0

Zwischen den Paketen 1:10.11.3-1 und 1:10.11.19-0+deb12u1 gibt es für Connector/J 5.1 keinen Unterschied: Jede geprüfte Treiberversion verhielt sich gleich, auch nach dem Update an Ort und Stelle. Der Treiber sieht beide Server als MySQL 5.5.5-10.11…, und mariadb-upgrade tut nach einem Update innerhalb des Zweigs nichts. Entscheidend ist das Präfix 5.5.5-, das es ab MariaDB 11.0.1 nicht mehr gibt (MDEV-28910). Server ab 11.4 bieten dazu TLS ohne jede Konfiguration an, mit einem beim Start erzeugten Zertifikat.

Derselbe „Connector/J 5“ verhält sich auf drei Arten

Auf MariaDB ab 11.0 verbinden sich die Releases bis 5.1.37 ohne TLS, 5.1.38 bis 5.1.45 gar nicht, und 5.1.46 bis 5.1.49 über TLS ohne Zertifikatsprüfung, wobei sie bei jeder neuen Verbindung eine mehrzeilige Warnung in coldfusion-error.log schreiben. Zwei Server mit „demselben“ Treiber können sich also unterscheiden. Die Version lesen wir im Manifest des Jar (Implementation-Version: 5.1.44), nicht im Namen des Verzeichnisses.

Die Liste der TLS-Protokolle steckt im Treiber

In den Releases 5.1.38 bis 5.1.45 bietet die Klasse ExportControlled TLSv1.2 nur MySQL-Servern ab 5.6 in der Enterprise-Edition an. Jeder andere Server bekommt TLSv1.1,TLSv1. Java 21 führt beide Protokolle in jdk.tls.disabledAlgorithms (im Oracle JDK seit 11.0.11), also endet der Handshake mit „No appropriate protocol“, bevor irgendetwas beim Server ankommt. Ab 5.1.46 bekommen auch Server ab 8.0.4 TLSv1.2.

„NonTransient“ und „reconnect“ führen in Richtung Netzwerk

ColdFusion öffnet die physische Verbindung über connectWithRetries, auch ohne autoReconnect=true in der Adresse. Der Treiber versucht es dreimal, jede Anfrage wartet 4,03 s auf den Fehler, und unter Last sind die Threads von ColdFusion vor allem mit Warten beschäftigt. Die eigentliche Ursache ist das dritte Caused by in exception.log. Firewall oder Verbindungslimit der Datenbank zu prüfen, kostet hier nur Zeit.

Der Typ „MySQL“ in ColdFusion 2025 ist eine Sackgasse

Der Typ „MySQL“ erwartet die Klasse com.mysql.cj.jdbc.Driver, also Connector/J 8 oder neuer, den Adobe nicht mitliefert. Ohne dieses Jar meldet die Quelle „No suitable driver available for … The mysql package is not installed.“, und cfpm.sh install mysql antwortet „mysql(2025.0.08.331874) package is already installed.“, weil das Paket mysql der Treiber von DataDirect ist. Der richtige Weg ist der Typ „Other“, wie in der Wissensdatenbank von Adobe.

Das Jar zu tauschen reicht nicht, und der neueste Treiber hat andere TLS-Vorgaben

MariaDB Connector/J 3.x und 4.x registriert sich nur für jdbc:mariadb:; die alte Adresse jdbc:mysql:// endet mit „No suitable driver found“, deshalb muss jede Datenquelle geändert werden. Version 4.0.0 vom Oktober 2026 braucht Java 17 und hat standardmäßig sslMode=verify-full. Mit der Datenbank aus Debian 12 ohne TLS endet sie mit:

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“ verändert Datentypen

Der Typ „MySQL“ hängt tinyInt1isBit=false an die Adresse, „Other“ nicht. Ohne diesen Parameter liefern beide Treiberfamilien TINYINT(1) als Boolean, und ColdFusion zeigt die Werte 0, 1, 2 als NO, YES, YES. Daten 0000-00-00 00:00:00 meldete Connector/J 5.1 mit dem Fehler „Value '0000-00-00 00:00:00' can not be represented as java.sql.Timestamp“, MariaDB Connector/J liefert einen leeren Wert. Code, der sich auf das eine oder das andere verließ, verhält sich anders.

Jeder Datenbankneustart hinterlässt tote Verbindungen im Pool

Ein Paketupdate startet MariaDB neu, und ColdFusion hält Verbindungen offen. Jede davon liefert bei der ersten Nutzung einen Fehler: Bei 8 Verbindungen im Pool endeten 8 von 12 folgenden Anfragen mit Fehler, in beiden Runden. Dasselbe Symptom nach einem gewöhnlichen Update innerhalb von 10.11 hält man leicht für einen Treiberfehler:

"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"

Der erste Eintrag stammt von Connector/J 5.1, der zweite von MariaDB Connector/J; seine Ursache in exception.log ist java.io.EOFException: unexpected end of stream, read 0 bytes from 4 (socket was closed by server). „Validate connection“ mit der Abfrage SELECT 1 hat diese Fehler vollständig beseitigt, 0 von 12.

Zwei Reihen mit je fünfzehn Quadraten für die Releases von Connector/J 5.1.34 bis 5.1.49. Reihe MariaDB 10.11: alle Quadrate schwarz. Reihe MariaDB 11.8: drei schwarz, acht orange Umrisse mit Kreuz, vier Quadrate mit Schloss unter der Klammer TLS

Der Wechsel zu MariaDB Connector/J Schritt für Schritt

Der Treiber

MariaDB Connector/J 3.5.11 kommt nach cfusion/lib, das alte Jar wird entfernt: Zwei Treiber für jdbc:mysql: in einem Verzeichnis bitten um Ärger. Danach ein Neustart von ColdFusion.

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-Dienst>

Den Zweig 3.5 haben wir bewusst gewählt: Er läuft auf jeder Java ab 8, verlangt von der Datenbank auf localhost kein TLS und wird parallel zu 4.0 gepflegt (Stand 2026-11). Auf ColdFusion mit Java 17 oder 21 ist 4.0 möglich, dann aber mit TLS auf dem Datenbankserver oder ausdrücklich sslMode=disable für die lokale Verbindung.

Die Datenquelle im ColdFusion Administrator

Data & Services, Data Sources, Treiber „Other“, die JDBC-Adresse:

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

Die übrigen Felder:

Feld	Wert
CF Data Source Name	unverändert (der Code verwendet ihn)
JDBC URL	die Adresse oben
Driver Class	`org.mariadb.jdbc.Driver`
Driver Name	MariaDB Connector/J
User name, Password	unverändert
Maintain connections	eingeschaltet
Validate connection, Validation Query	eingeschaltet, `SELECT 1`

Alle Quellen mit einem Skript

Das Skript über die Admin API läuft einmal von localhost, zuerst mit run=0 als Vorschau, dann mit run=1. ColdFusion legt vor dem Speichern eine Kopie neo-datasource.bak an, eine eigene Kopie von neo-datasource.xml schadet trotzdem nicht.

<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>

Der Schlüssel ist encryptpassword=false: getDatasources() liefert das Passwort bereits verschlüsselt, also überträgt das Skript es, ohne die Datenbankpasswörter zu kennen, zusammen mit den SQL-Rechten der Quelle und den Einstellungen für CLOB und BLOB. Ergebnis: 7 Quellen umgestellt, verify: YES bei jeder. Die Validierung der Verbindungen schaltet der Administrator ein oder derselbe Aufruf setOther mit validateConnection=true, validationQuery="SELECT 1". Die Skriptdatei löschen wir gleich nach der Nutzung vom Server, weil sie das Administratorpasswort enthält.

Prüfung vor der Übergabe

Leseabfragen, cftransaction mit UPDATE, gespeicherte Prozeduren, TINYINT(1)-Spalten mit den Werten 0, 1, 2 wie vor der Änderung und die Stellen, an denen der Code Nulldaten prüft. Bei den Prozeduren fiel der Unterschied positiv aus: Connector/J 5.1 meldete bei einer Prozedur eines anderen Benutzers „User does not have access to metadata required to determine stored procedure parameter types“, MariaDB Connector/J braucht keinen Zugriff auf ihren Text.

Eine Überbrückung, bis die Umstellung vorbereitet ist

Wenn die Umstellung warten muss und die Datenbank auf demselben Server liegt, verbindet sich Connector/J 5.1.38 bis 5.1.45 mit MariaDB ab 11.0, sobald useSSL=false in der Adresse steht; enabledTLSProtocols=TLSv1.2 wirkt erst ab 5.1.44. Das ist eine Überbrückung, keine Lösung: Der Treiber wird seit 2021 nicht mehr weiterentwickelt.

Vor dem nächsten Datenbankupdate

mariadb -e "SELECT VERSION()"                      # 10.x oder 11.x und neuer
apt-cache policy mariadb-server                    # woher das Paket kommt und auf welche Version es wechselt
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

Ein Blatt mit der Beschriftung Admin API, von dem eine orange Sammelleitung über sieben gleichmäßige Bahnen zu sieben kleinen Datenbanken führt, über den Bahnen die Aufschrift jdbc:mariadb, an jeder Datenbank ein Haken

Was wir daraus mitnehmen

Ein von Hand eingespielter JDBC-Treiber ist eine Abhängigkeit, an die niemand denkt, bis die Datenbank den Zweig wechselt. Connector/J 5.1 wird seit 2021 nicht mehr weiterentwickelt und wartete nur auf die erste Änderung, die er nicht übersteht. Solche Funde sind typisch bei der Übernahme und Wartung eines Systems.
Die Meldung von ColdFusion beschreibt das letzte Symptom, nicht die Ursache. Hier war die Ursache das dritte Caused by, und die Wörter „NonTransient“ und „reconnect“ führten in Richtung Netzwerk.
Der Wechsel zu MariaDB Connector/J ist mehr als ein Dateitausch. Ein anderes Adressschema, eine andere Klasse, andere TLS-Vorgaben in 4.0 und eine andere Typzuordnung als beim Typ „MySQL“. Das Skript über die Admin API erledigt das wiederholbar und prüft sofort.
Die Validierung der Verbindungen im Pool kostet eine leichte Abfrage und beseitigt die Fehler nach jedem Datenbankneustart, auch nach einem gewöhnlichen Sicherheitsupdate.
Ein Datenbankupdate planen wir zusammen mit der Anwendung. Die Version der Datenbank vorher und nachher, die Treiberversion aus dem Manifest des Jar und drei Phrasen in den Logs von ColdFusion, nicht nur im Log der Datenbank.

Dasselbe Paar aus ColdFusion und MariaDB Connector/J unter hoher Last zeigt das Projekt JVM heap space; die Installation von ColdFusion 2025 Update 8 hinter Apache beschreibt das Projekt ColdFusion 2025, die Arbeit an der MariaDB selbst das Projekt SQL-Indizes.

Ihre ColdFusion-Anwendung verbindet sich nach einem Datenbankupdate nicht mehr mit MariaDB, oder in den Logs steht „Attempted reconnect 3 times. Giving up.“? Wir finden die Ursache anhand der Logs, stellen die Datenquellen ohne Änderungen am Code auf einen aktuellen Treiber um und prüfen die Daten vorher und nachher. Der erste Schritt ist ein Erstgespräch.

Quellen

Die Angaben zu Versionen und Standardwerten stammen aus Veröffentlichungen der Hersteller (Stand: 2026-11):

Zwei Reihen mit je zwölf Quadraten für Anfragen nach einem Datenbankneustart. Die obere Reihe ohne Schranke: die ersten acht Quadrate sind orange Umrisse mit Kreuz, vier schwarz. Die untere Reihe läuft durch eine Schranke mit der Aufschrift SELECT 1: alle zwölf Quadrate schwarz

Weitere Projekte

Das MySQL-Backup hatte 751 Byte: eine beschädigte MyISAM-Tabelle und der Wiederherstellungstest

Das Cron-Skript schrieb sieben Nächte lang statt rund 280 MB eine Datei mit 751 B: Eine MyISAM-Tabelle war als beschädigt markiert, mysqldump brach bei LOCK TABLES ab, das Skript endete mit Code 0, Cron verwarf die Meldung. Wir haben den Ausfall nachgestellt, die Tabelle repariert, auf InnoDB umgestellt und ein Backup eingeführt, das jede Nacht probeweise zurückspielt und Alarm gibt.
Ein Spamfilter, der lief, aber nicht schützte

Dienste liefen, die Konfiguration war gültig, im Systemstatus stand kein Fehler. Trotzdem landete Phishing im Posteingang, während Newsletter von Partnern im Spam lagen. Unsere Ingenieure haben gemessen, welche Erkennungsmechanismen tatsächlich ansprangen, die Ursachen behoben und drei Monate später eine Regression gefunden und behoben, die sich nur stundenweise zeigte.

In 20 Minuten klären wir, welcher erste Schritt zu Ihrem System passt

Sie schildern Ziel und Stand, wir sagen offen, ob und wie wir helfen können. Antwort innerhalb eines Werktags, unverbindlich.

Erstgespräch vereinbaren So arbeiten wir

Telefon (Deutsch, Polnisch, Englisch) +48 501 250 220

E-Mail E-Mail

Erreichbar: Montag bis Freitag, 9:00 bis 17:00 Uhr (MEZ); Support und Notfälle rund um die Uhr (24/7)

ColdFusion nach dem MariaDB-Update: „Attempted reconnect 3 times. Giving up.“ mit Connector/J 5.1 und der Wechsel zu MariaDB Connector/J

Ausgangslage

Lösung

Ergebnisse

So sind wir vorgegangen

Die Logs von ColdFusion

Eine JDBC-Sonde außerhalb von ColdFusion

Zuerst die einfachste Hypothese

Neuere Zweige von MariaDB

Eine Matrix der Treiber

Der Code des Treibers

Umstellung und Unterschiede in den Daten