Plötzliches Problem mit PHP-Skript: Es wird nicht auf Beendigung von Datenbankoperationen gewartet (Transaktion)

  • PHP

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von Link.

    Plötzliches Problem mit PHP-Skript: Es wird nicht auf Beendigung von Datenbankoperationen gewartet (Transaktion)

    Ich habe ein PHP-Skript geschrieben, welches via Cronjob regelmäßig aufgerufen wird (ein manueller Aufruf ist logischerweise auch möglich). Es wird eine CSV-Datei eingelesen und anschließend werden diese Werte in eine Datenbank geschrieben. Am Ende wird ausgegeben, wieviele Werte es waren.

    Derzeit teste ich unter Windows und obwohl ich lange Zeit kein Update des installierten WAMP-Pakets ("Wampserver") installiert habe, hat sich das Verhalten des Skripts seit meinem letzten Test (vor wenigen Monaten) deutlich geändert. Getestet mit PHP 8.0.20 und gerade auch mit 8.0.26. Und zwar:

    Es erfolgt sofort nach Aufruf der PHP-Datei die Meldung der importierten Datensätze, aber alles ist "0". Im Hintergrund läuft der MySQL- bzw. MariaDB-Server (Version 10.5.16) aber noch und trägt alles ein. Die Daten sind dann auch drin, aber das PHP-SKript ist offenbar schon lange beendet. Wie ist das möglich? Ich arbeite zwar mit einer Transaktion (begin_transaction() und commit()), aber trotzdem kann doch das Übermitteln der Werte nicht in 10 ms gehen, während der Datenbankserver nach PHP-Ausführung noch sekundenlang arbeitet. Und vor allem: Dieses Verhalten war nicht immer so. Das verwundert mich am meisten.

    Hat jemand eine Idee, was hier das Problem sein kann? Der Code ist sehr umfangreich, daher poste ich den nicht. Ich könnte höchstens eine abgespeckte Version erstellen, aber da steht dann auch nicht mehr drin als ich hier geschrieben habe.

    EDIT: Es scheint ein reines Firefox-Problem zu sein (in Chrome geht's), da bin ich zumindest zu 99% sicher. Also ist es evtl. ein Cache-Problem, wie schon 2011 mal jemand hier schrieb: stackoverflow.com/questions/83…omplete-before-proceeding

    Ich denke, das Thema ist damit erledigt, auch wenn ich es sehr befremdlich finde, dass Firefox an dieser Stelle etwas cachet und direkt den Cache zurückgibt, obwohl die Ausführung des Skripts noch läuft. Da muss sich was bei einem der letzten FF-Updates geändert haben.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Ich bin etwas verwirrt wie du von Cronjob zu Browser kommst, rufst du das Script zum testen mit dem Browser auf?
    Wenn ja, welche Header liefert der Webserver denn zurück?

    Alternativ, ruf das Script doch in der Konsole auf: php dein-script.php
    Da habe ich mich tatsächlich etwas verwirrend ausgedrückt. Ja, ich rufe das Skript zum Testen im Browser auf.

    Mittlerweile kann ich zu 100% bestätigen, dass es ein Cache-Problem ist/war. Wie im verlinkten Thread bei stackoverflow empfohlen, habe ich header("Cache-Control: no-cache, must-revalidate"); eingefügt. Eigentlich müsste header('Cache-Control: no-store'); besser/richtiger sein, aber das bewirkt keinen Unterschied.

    Das Rätsel ist also gelöst. :)

    EDIT: Oder auch nicht ... Im Firefox wird immer gecachet, das ist durch nichts zu verhindern. Nicht einmal durch folgendes:

    PHP-Quellcode

    1. header('Expires: Mon, 12 Jul 1995 05:00:00 GMT');
    2. header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
    3. header('Cache-Control: no-store, no-cache, must-revalidate');
    4. header('Cache-Control: post-check=0, pre-check=0', false);
    5. header('Pragma: no-cache');

    Dann kann ich eben in Firefox das nicht mehr testen ... :(
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Kannst du das mit einem mini Script irgendwie mal zeigen?
    Zusätzlich könntest du in Firefox, zum testen, die DevTools öffnen, im Reiter "Network" gibt es eine Option "Disable Cache" (rechter oberer Bereich).
    Mit geöffneten DevTools und dem aktivierten "Disable Cache" scheint es zu funktionieren.

    Ich finde es sehr schwierig, eine abgespeckte Version des Skripts zu machen. Im Prinzip müsste quasi sowas reichen:

    PHP-Quellcode

    1. <?php
    2. $random = rand(1, 10);
    3. echo "Random number: $random";

    Ich bin gerade nicht an dem Rechner, wo das auftritt, aber da müsste jedes Mal die Zahl kommen, die beim ersten mal gekommen ist. In meinem Code sind vor der Ausgabe einfach noch Dinge wie Einlesen der CSV und Senden an die DB, was durchaus 10 Sekunden dauern kann.

    So oder so scheint es kein PHP-Problem zu sein, sondern einfach eine Eigenheit von Firefox.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum
    Hm bei mir kommt da jedes mal eine andere Zahl (wie es sein sollte), da kommt nichts aus dem Cache.
    Kann aber auch an meiner Konfiguration von Webserver liegen.
    Ich werde nächste Woche mal schauen, ob ich das mit diesem Miniskript reproduziert bekomme. Evtl. muss ich noch ein Sleep oder dergleichen einbauen, vielleicht ist die neue FF-Version nicht mehr so geduldig.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Neu

    @Marcus Gräfe oft lassen sich Caching-Mechanismen überlisten, indem man einen random string an die URL mit dran hängt, in der Art "?rnd=`sha1(microtime(true))`".
    Irgendein schwindliges Caching-Pugin läuft in FF auch nicht, oder? Ne alternative könnte es noch sein, Postman zu benutzen(?)
    Gibt's seither ggf. ein FF Update, das diesen Fehler behebt?


    www.xmgr.de
    PHP lernen | Programmierung | Sonstiger Krempel
    Zum Blog | PHP lernen | GitHub

    Neu

    Da das Skript meist über einen Linux-Cronjob aufgerufen wird, wo es logischerweise keinen Cache gibt, ist das mit dem Zufallsstring nicht unbedingt erforderlich.

    Anfangs dachte ich an einen PHP-Fehler. In dem Augenblick, wo mir klar wurde, dass es ein Cache-Problem von Firefox ist, war das Problem nicht mehr wirklich akut. Zwar möchte ich noch versuchen, das Problem mit einem kleinen Skript zu reproduzieren, aber das mache ich nur aus Neugier. Ich würde das Ergebnis dann natürlich hier auch posten.

    Und nein, ich habe kein Plugin im FF installiert, was in irgendeiner Form was mit dem Cache macht.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Neu

    Da das Skript meist über einen Linux-Cronjob aufgerufen wird, wo es logischerweise keinen Cache gibt, ist das mit dem Zufallsstring nicht unbedingt erforderlich.

    Ja ach ne, CLI arbeitet ja auch nicht mit URLs, lol^^

    Es scheint als wär Firefox da wirklich so hartnäckig dass man das nicht aus PHP heraus umgehen kann - bzw wäre können nicht mal das Problem, Firefox müsste ja nur die gesendeten Header richtig verarbeiten. In der about:config könnte man noch die Einstellungen für browser.cache.disk.enable und browser.cache.memory.enable anpassen, was halt auch ranzig ist eigentlich. Ggf könnte (ist eigl nur ne wilde Idee) die Reihenfolge der gesendeten Header noch Einfluss haben.
    Das letzte was mir noch einfallen würde auszuprobieren wäre, die URL von einem anderen Gerät aus mit Firefox aufzurufen. Ab und zu so scheint's mir ist Firefox mit dem Cache Handling schlampig, sodass auch nach geleertem Cache keine Änderung auf der Seite zu sehen ist, mit einem anderen Browser klappt es dann.

    Anyway, interessant find ich das Problem schon ziemlich, bin gespannt ob es noch sowas wie eine Lösung geben wird.


    www.xmgr.de
    PHP lernen | Programmierung | Sonstiger Krempel
    Zum Blog | PHP lernen | GitHub

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Link“ ()