www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/66862b27-42ff-4b33-b3dd-930402dcad74/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

Doctrine\DBAL\Exception\LockWaitTimeoutException: An exception occurred while executing a query: Lock wait timeout exceeded; try restarting transacti…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse: Lock Wait Timeout Exceeded in TYPO3¶

1. Ursache identifizieren¶

Der Fehler mysqli_sql_exception: Lock wait timeout exceeded; try restarting transaction ist ein MySQL/MariaDB-InnoDB-Problem: Eine laufende Transaktion hält einen exklusiven Lock auf einer Datenbankzeile (oder Zeilen) und eine zweite Transaktion (der aktuelle TYPO3-Request) kann nicht darauf zugreifen, weil das konfigurierte Wartezeitlimit (innodb_lock_wait_timeout, Standard: 50 Sekunden) überschritten wurde.

Konkrete Analyse des Stack Traces:

• Der Fehler tritt während des HTTP-Request-Lifecycle auf – bevor das Frontend oder Backend eigentlich gerendert wird
• Die beteiligten Middleware-Komponenten (VerifyHostHeader, NormalizedParamsAttribute, ResponsePropagation) greifen auf Session- und Konfigurationsdaten zu
• Wahrscheinlichste Ursachen:

Schlüsselbeobachtung: Der Fehler erfolgt bereits in der Middleware-Phase (MiddlewareDispatcher::handle), was darauf hindeutet, dass die Datenbank-Operation frühe Initialisierung betrifft – typischerweise Session-Handling (fe_typo_user) oder TypoScript-/Konfigurationsaufbau.

2. Fix beschreiben (konkret)¶

Sofortmaßnahme (Symptom beheben):

-- Blockierenden Prozess identifizieren:
SHOW ENGINE INNODB STATUS\G

-- Alle aktiven Transaktionen prüfen:
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started;

-- Blockierenden Prozess beenden:
KILL [process_id];

Konfiguration (Prävention):

-- Lock-Wait-Timeout erhöhen (in my.cnf / my.ini):
innodb_lock_wait_timeout = 120

-- Gleichzeitig Timeout-Prüfung in TYPO3 prüfen:
-- In LocalConfiguration.php / AdditionalConfiguration.php:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['dbClientCompress'] = false;

Langfristige Lösungen:

1. Root-Cause-Suche: SHOW ENGINE INNODB STATUS regelmäßig prüfen, um den blockierenden Query zu identifizieren
2. Langlaufende Queries optimieren: Besonders Scheduler-Tasks und Import-Scripts prüfen
3. Index-Optimierung: Fehlende Indexe auf häufig gelockten Tabellen hinzufügen
4. Transaktionsdauer minimieren: In Extensions sicherstellen, dass Transaktionen kurz gehalten werden
5. Page-Cache aktivieren: Reduziert DB-Zugriffe erheblich ($GLOBALS['TYPO3_CONF_VARS']['FE']['enable_pagecache'])
6. Connection Pooling: Prüfen, ob nicht zu viele gleichzeitige Verbindungen geöffnet sind

TYPO3-spezifisch:

// In AdditionalConfiguration.php – ggf. DB-Timeout anpassen:
$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['driverOptions'] = [
    \PDO::ATTR_TIMEOUT => 5,
    \PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true,
];

3. Betroffene TYPO3 Extension¶

Da der Stack Trace ausschließlich Core-Komponenten zeigt und keine Third-Party-Extension im Trace sichtbar ist, ist die betroffene Ebene der TYPO3 Core selbst.

Allerdings ist der Verursacher wahrscheinlich eine der folgenden Extensions:

Hinweis: Ohne genauere Angabe der installierten Extensions ist eine definitive Zuordnung nicht möglich. Der Fehler kann durch jede Extension verursacht werden, die long-running Transaktionen ausführt.

Tipp zur Identifikation:

-- Blockierende Query identifizieren:
SELECT trx_mysql_thread_id, trx_query, trx_started, trx_state 
FROM information_schema.INNODB_TRX 
WHERE trx_state = 'LOCK WAIT';

4. Confidence¶

Gesamte Confidence: ~75%

Der Error-Code ist eindeutig und die Analyse des Stack Traces erlaubt eine klare Zuordnung zum InnoDB-Layer. Die Identifizierung der spezifischen verursachenden Extension erfordert jedoch zusätzliche Datenbank-Analysen (SHOW ENGINE INNODB STATUS).