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

  • PHP

Es gibt 15 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
    @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?
    Hello World
    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
    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.
    Hello World

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

    Link schrieb:

    CLI arbeitet ja auch nicht mit URLs

    Wusste ich bis gerade eben ehrlich gesagt noch nicht. ;) Ich dachte, sowas wie php /var/www/doit.php?param=value müsste gehen. Jetzt weiß ich, dass das nicht so geht und Parameter anders übergeben werden.

    Ich habe jetzt nochmal versucht, das Problem mit einem Testskript zu reproduzieren. Leider ohne Erfolg. Bei meinem richtigen Skript ist der Fehler zu 100% reproduzierbar. Sogar fast 2 Wochen nach meinem letzten Aufruf ruft FF immer noch was gecachtes ab. Zwar wartet FF bis mein Skript beendet ist (ca. 10 Sekunden), aber das angezeigte Ergebnis danach ist das vor 2 Wochen.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Link schrieb:

    bin gespannt ob es noch sowas wie eine Lösung geben wird

    Jetzt habe ich die Lösung (also nicht ganz, aber ich kenne den Fehler). Der Fehler ist noch kranker als erwartet. Es ist auf jeden Fall ein Browser-Problem, vmtl. nur in Firefox (sonst nur in Chrome getestet).

    Drücke ich Strg + F5, so ist alles korrekt. Drücke ich nur F5, so wird das Skript 2x aufgerufen! Und zwar wirklich jedes Mal. Es ist auch egal, was das für ein Skript ist, wie lange es läuft und was es zurückgibt. F5 = 2 Aufrufe einer PHP-Datei in meinem FF. Ich habe testweise alle Add-ons deaktiviert, das Problem bleibt.

    Mit folgendem Code bin ich der Sache auf die Schliche gekommen:

    PHP-Quellcode

    1. <?php
    2. $random = rand(10, 20);
    3. echo $random;
    4. error_log($random);

    Ergebnis im Log: Immer 2 Zahlen, wobei die letzte die ist, die im Browser angezeigt wird.

    Daher verstehe ich nun auch mein ursprüngliches Problem: Ich rufe die Datei auf, sie startet den Import und blockiert (weil ich das so programmiert habe) einen gleichzeitigen weiteren Import. Nun wird das Skript aber direkt nochmal aufgerufen. Es gibt dann zurück, dass kein Import stattfand (was richtig ist, weil der Import schon läuft) und im Hintergrund läuft der eigentliche Import.

    Auf einem anderen PC mit Firefox, bestimmt eine andere Konfiguration und andere Add-ons, besteht das Problem übrigens ebenfalls.

    Ein Cache-Problem kann es eigentlich nicht sein.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

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

    Hab das gerade bei mir getestet, mit Firefox und kann das Problem nicht nachstellen.
    Im error log taucht die Zahl nur einmal auf und ist die gleiche die im Browser angezeigt wird.
    Ich habe es auf 3 PCs getestet, 2 zeigten das Verhalten, einer nicht. Es ist entweder eine Einstellung in FF (die zufällig auf beiden PCs gemacht wurde) oder es hat irgendwie mit der Serverrückgabe zu tun, z. B. irgendwelche Angaben im Header. Das Problem tritt bei einer Wampserver-Installation und bei einem normalen Ubuntu-20-System auf, jeweils PHP 8.0. Morgen werde ich wissen, ob eine XAMPP-Installation (unter Windows) das Problem auch hat. Falls nein, so wäre die Theorie mit der Serverrückgabe zumindest nicht gänzlich falsch.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum
    Die Lösung:

    Ein Service-Worker hatte alle PHP-Dateien auf dem Webspace gecacht. Dadurch trat dieser Doppelaufruf irgendwie auf. Letztendlich ein Fehler in allen Browsern und mit allen Servern, solange man den Service-Worker durch einmaligen Aufruf der eigentlichen Web-Applikation bzw. Website installiert hat. Nach einem Ausschluss von *.php geht es nun.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

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