contao/test — Issue #2616: Generelles Risiko der "localconfig-Leerung"
Author: NinaG
Created: 2011-11-29 09:59:06+00:00
State: open
Labels: backend, Defect

Es gibt bei einigen Nutzern das Problem, dass die localconfig.php von einem auf den anderen Tag fast leer ist. In den Diskussionen dazu im Forum kristallierte sich eine mögliche globale Ursache heraus, die in der Technik von Contao verankert ist.

**Peter (acenes) erklärte [hier im Thread](http://www.contao-community.de/showthread.php?937-TL-l%F6scht-eigene-config&p=70664#post70664) die potentielle Problemstellung:**

2 quasi gleichzeitige Seitenaufrufe von verschiedenen Clients.

Der erste liest die Config Datei ein und führt den cron Job aus. Dann will sie im Destructor der Config Klasse den neuen Ihalt mit dem geänderten cron Timestamp in die Datei speichern. Während der Schreiboperation kommt nun der zweite Seitenaufruf und liest die noch unvollständig gespeicherte neue Config Datei ein. Da haben wir dann das genau das Problem.

**Er postet auch gleich die [potentielle Lösungsstellung](http://www.contao-community.de/showthread.php?937-TL-l%F6scht-eigene-config&p=70664#post70664:**)

Die Schreiboperation im Destructor der Config Klasse per Semaphore schützen.
Auf Dateibasis aber nicht universell lösbar weil Semaphore-Dateien (wie in Unix/Linux üblich) bei Windows nicht funktionieren. Ich selber habe bei meiner cron Erweiterung deshalb einen Lock in MySQL verwendet. Im Destruktor der Config Klasse könnte das etwa so aussehen:

PHP-Code:

```
do {
$ql = $this->Database->prepare("select get_lock('configlock',0) as lockstate")->executeUncached();
} while (

![]($ql->next() || )intval($ql->lockstate));
$objFile = new File('system/config/localconfig.php');
$objFile->write($strFile);
$objFile->close();
$this->Database->prepare("select release_lock('configlock')")->executeUncached();
```

Zusätzlich wäre es natürlich sinnvoll auch den cron Job selber gegen doppelte Ausführung per Semaphore zu schützen.

**Dazu [merkte lindesbs folgendes an](http://www.contao-community.de/showthread.php?937-TL-l%F6scht-eigene-config&p=70668#post70668:**)

Bei dieser Art des Lockings aber beachten, das dies alle DatenbankTypen ausser MySQL aussperrt. Das muss in den DB_Drivern geschehen, so wie das Locking der Tabellen, was Leo genutzt hatte. Siehe http://dev.contao.org/issues/2068

**acenes [ergänzte](http://www.contao-community.de/showthread.php?937-TL-l%F6scht-eigene-config&p=70676#post70676:**)
Richtig, ausserdem müsste man das Lesen mit dem gleichen Lock schützen, sonst hat man nur die halbe Lösung.

Besser wäre es wohl, die cron Timestamps in der DB zu speichern statt in der Config Datei.

**lindesbs [ergänzte](http://www.contao-community.de/showthread.php?937-TL-l%F6scht-eigene-config&p=70680#post70680:**)
Genau, und mit den Timestamps auch ein Locking. Zusaetzlich eine Kontrolle das die PHP Timeout nicht groesser als der Zeitabstand des Cron ist.

Ich hoffe, dass ich das so sinnvoll zusammengefasst habe. So wie ich das als Nicht-PHPler verstehe, ist das ein generelles Problem das theoretisch bei jedem auftauchen könnte und deshalb im Core behoben werden sollte.

--- _Originally created on October 14th, 2010, at 02:46pm (ID 2616)_