Chestarbargel

Servus,

ich habe vor einer Weile eine Session-Klasse geschrieben, die nun die Session in einer Datenbank(MySQL) statt im Dateisystem speichert.
In rund 0,003% der Fälle tritt aber ein Problem beim speichern der Session auf, bei dem ich nicht weiterkomme.
Das speichern der Session wird im destructor ausgeführt, welcher ja automatisch am Skriptende aufgerufen wird.

Und zwar wurde die MySQL-Verbindung wegen einem timeout bereits geschlossen, und daher schlägt das schreiben mit dem Fehler:
2006: MySQL server has gone away
fehl.

Eine Fehleranalyse brachte nun folgendes zu Tage:
Zwischen dem erstellen des Sessions-Objekts und dem zerstören des Session-Objekts liegen zB. 30, 60, 90, 120, usw.Sekunden(Zeitmessung im constructor/destructor).
Nun liegt aber die maximum_execution_time bei 30 Sekunden.
Die Seite selber wird aber immer in weniger als 1 Sekunde fertiggestellt(Zeitmessung zwischen dem ersten und letzten php-Befehl)

Ich habe schon geprüft, dass nirgendwo:
-Die maximum_execution_time heraufgesetzt wird
-Nirgendwo set_time_limit für den Fehler verantwortlich ist

Ich nutze php 5.2.6 und bin ein wenig ratlos, und wäre für weiterführende Tipps dankbar.

Grüße,
Chestarbargel

Mister Ad

dr.e.

Hallo,

ich vermute, dass dir hier die Implementierung des Destruktor-Verhaltens einen Streich spielt. Soweit ich das im Kopf habe, entscheidet PHP selbst über die Reihenfolge der Destruktion von Objekten oder richtet sich nach der Reihenfolge der Erstellung deiner Objekte. In beiden Fällen hast du das Problem, dass du nicht deterministisch sagen kannst, wann deine Session-Klasse die Sessions persistiert. Sollte also deine Datenbank-Abstraktionsschicht vor deiner Session-Klasse destruktiert werden, ist die MySQL-Verbindung logischerweise weg.

Die großen Zeitunterschiede zwischen Konstruktor und Destruktor kann ich mir auch nicht erklären.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Chestarbargel

Seruvs.
Dieses Verhalten ist mir bekannt.
Ich ging davon aus, dass ich es mit:
umgehen kann.
Das Session-Objekt erzeugt dadurch eine eigene Verbindung zur Datenbank. (Nach dem Studium weiterer fortgeschrittener Konzepte, erscheint mir das momentan auch nicht mehr unbedingt als sinnvoll)

Wenn also durch den Destructor der mysql-Klasse auch der parent von session destruktiert wird, ist mir das Verhalten klar.

Bei den langen Laufzeiten wundert mich, das es in allen Fällen vielfache der maximum_execution_time sind. Als ich testweise den Wert auf 20 Sekunden gesetzt habe, waren es 40,80,100 usw. Sekunden.

Grüße,
Chestarbargel

David

Benutzt Du session_set_save_handler() oder ist das ganze "Freihand"-implementiert?

Chestarbargel

Servus.

Ich benutze
session_set_save_handler
im constructor sowie
session_write_close
im destructor.

Grüße,
Chestarbargel

David

Wenn Du set_save_handler benutzt, wird die angegebene Funktionen
callback $close und callback $write von PHP aufgerufen, wenn es an der Zeit ist, die Session-Daten zu sichern. Das mit dem Destruktor zu verknüpfen, "fühlt" sich nicht richtig an.
Damit habe ich mich noch nicht beschäftgt, aber wie gessagt, es ein "Gefühl", dass das nicht passt.
Ich weiss ja nicht, wie der Code genau aussieht, aber einfache Überlegung: session_set_save_handler(array($this, 'onOpen'), array($this, 'onClose'), ...
Damit besteht eine Referenz auf das Objekt in der Session-Verwaltung.
Das Objekt kann nur dann "gracefully" abgebaut werden, wenn es keine Referenz mehr gibt. Du beendet die Session aber erst explizit im Destruktor des Objekts.
Wann wird also was abgebaut? Meine Vermutung ist: PHP löst diesen "Konflikt" nicht (oder anscheined nicht immer) so auf, wie Du es erwartest.

dr.e.

Das würde ich auch so erwarten, ich habe aber gerade in den letzten Tagen gesehen, dass während des Shutdowns bzw. der Destruktion offensichtlich andere Regeln (Referenzen) gelten.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

David

Genau das meine ich ja.
Ich kann mir mehrere Szenarien vorstellen in Bezug auf die Referenz- und Resourcenverwaltung und dem Beenden der PHP-Instanz, bei der es hier knallen kann.

Chestarbargel

Servus.

Am Ende eines Skriptes werden ja zuerst die Objekte zerstört, und dann die Session geschrieben.
Daher ging ich davon aus, dass ich spätestens beim zerstören des Sessionobjektes die Session schreiben muss.
Dem ist dann nicht so, daher habe ich den Aufruf entfernt.

Dadurch wurde die Session sogar früher geschrieben als ohne den expliziten Aufruf von session_write_close im destructor.

Mir ist zusätzlich noch aufgefallen, dass ich es sogar direkt nach dem erstellen wieder zerstören kann(ohne session_write_close im destructor), und die Sessions werden trotzdem sauber am Ende des Skriptes gespeichert.

Habe nun über nacht nochmal Logs erstellen lassen, um genauer sehen zu können, was passiert. Dabei lief die session schon ohne den expliziten Aufruf von session_write_close im destructor.

Fazit:
Problem bleibt das gleiche, in seltenen Fällen habe ich gemessene Zeiten zwischen dem öffnen und schreiben einer Session, die größer als max_execution_time sind.
Die Skripte werden auch nicht mit einem Fatal-Error beendet.
Und nur in den Fällen mit diesen riesigen Zeiten, tritt eben der Fehler auf.

Zählt die Scriptabschaltung nicht mehr zur max_execution_time dazu?
Dann wäre schonmal die Sache an sich nicht mehr so unklar, ich müsste nur noch herausfinden, wieso er manchmal so ewig braucht, bis das schreiben der Session ausgeführt wird.

Grüße,
Chestarbargel

David

Ich fürchte, das können wir ohne den kompletten Code nicht aufklären.