[dsxs]

Für meine Sessions benutze ich einen eigenen Sessionhandler (Klasse), welcher die Sessiondaten jeweils in einer Datenbank ablegt.
Die Kommunikation mit der Datenbank kommt durch einen globalen Datenbankhandler zustande (Klasse).

Hier ein schematischer Ablauf:

Instanz des Datenbankhandlers wird erstellt
Instanz des Sessionhandlers wird erstellt
........
Sessionhandler wird geschlossen
Datenbankhandler wird geschlossen


Nun hat mein Hoster nach dem Release der neuen PHP Version 5.2.0 diese Version installiert, worauf Probleme aufgetaucht sind.

V. 5.2.0 scheint einige Änderungen im Bezug auf die Handhabung von Klasseninstanzen gebracht zu haben, und zwar, so denke ich, werden diese nun in verkehrter Reihenfolge geschlossen (nach Ausführung des Scripts).

In meinem Fall heisst das, dass das Datenbank-Objekt geschlossen wird, bevor der Sessionhandler seine Daten in der Datenbank abgelegt hat.

Mein Hoster hat inzwischen wieder ein downgrade gemacht (die neue Version scheint noch viele andere Bugs zu haben, die u.a. Wordpress zu schaffen machen...)

Bezüglich dieses Themas habe ich lediglich folgende Quelle: http://bugs.php.net/bug.php?id=39381

Scheinbar bin ich nicht der Einzige, dem dieses möglicherweise neue Verhalten zu schaffen macht. Am 10 November 06 schreibt jedoch ein gewisser Tony (siehe URL), dass weder eine Änderung seit 5.2.0 passiert sei, noch dass es jemals eine Reihenfolge im "Killprozess" der Klassen gegeben habe.

Kann dies jemand bestätigen?


Gruss,
dsxs

[Byrel]

Naja eigentlich ja nur logisch.

Ich erstelle Objekt1 und dann erstelle ich Objekt2 d.h. Objekt2 könnte von Objekt1 abhängig sein.

Würde ich jetzt zuerst Objekt1 zerstören, würde die Zend Engine in einen inkonsistenten Zustand sein und PHP wahrscheinlich abstürzen oder was auch immer, weil eben Objekt2 Methoden oder Variablen von Objekt1 verwenden könnte, die dann aber nicht mehr existieren würden.

Jetzt könnte man natürlich hergehen und überprüfen ob ein Objekt noch irgendwo verwendet wird und wenn das nicht der Fall ist, kann man es zerstören. Das wäre aber wesentlich schwerer zu implementieren, fehleranfälliger und langsam.

Ob das in früheren Versionen auch so war weiß ich nicht (müsste man ausprobieren), ich nehme allerdings an, dass es so war.

MfG Byrel

[dsxs]

Das ists ja gerade:

Datenbankhandler: Objekt 1
Sessionhandler: Objekt 2

Wobei in meinem Fall Objekt 2 von Objekt 1 abhängig ist.

Dies scheint in PHP 5.2.0 jedoch der Fall zu sein, die Objekte werden verkehrt herum zerstört, wobei wir wieder bei meiner Frage sind: trifft das zu?

[Byrel]

Jo, ist imo auch nur logisch. Die Objekte die zuerst erstellt werden, werden als letztes zerstört. Oder reden wir aneinander vorbei?

MfG Byrel

[dsxs]

Zitat von Byrel

Jo, ist imo auch nur logisch. Die Objekte die zuerst erstellt werden, werden als letztes zerstört. Oder reden wir aneinander vorbei?

Völlig

Ich stimme mit dir überein, dass es nur logisch ist, das zuerst erstellte Objekt auch zuletzt zu zerstören, das 2. als zweitletztes usw.

Nun scheint php 5.2.0 dies jedoch genau anders zu machen, und zwar wird zuerst das Objekt gelöscht, welches zuerst erstellt wurde, was dann Konflikte mit Objekten verursacht und im folgenden Klassiker endet:

Fatal error: Call to a member function asdf() on a non-object in
/www/asdf.php on line 46


Meine Frage lautet: sehe ich das richtig, dass die neue Version in dieser Sache einen schwerwiegenden Fehler hat oder trifft folgende Aussage von diesem tony (siehe URL) zu?
Ich würde gerne den Usprung finden, der meine Scripte mit Version 5.2.0 nicht mehr laufen lässt, bevor mein Hoster bald einmal erneut upgradet.

There is no certain order of object destruction, there never was and
this is explained in many other reports.

You have to take care of the correct destruction order yourself.

[MrNiceGuy]

Ich hatte mal irgendwann etwas gelesen, was mit einer ähnlichen Thematik zu tun hatte. In dem Thread ging es um eine Änderung was den Destruktor betroffen hat, kann mich aber gerade nicht genau daran erinnern, was Thema ansich war oder wo ich das gelesen habe. Da hatte sich jedoch auch irgendeine Reihenfolge geändert. Mag aber auch sein, dass das von Version 4 auf 5 war?! Mist, ich hoffe es fällt mir noch wieder ein...

[Basti]

Hi.

Ich finde die Idee auch schräg, sich darauf zu verlassen, dass PHP nach Beendigung eines Skriptes irgendwelche Jobs macht oder die Objekte in einer vorgegebenen Reigenfolge zerstört. Wo wäre letzteres denn dokumentiert, dass man darauf bauen könnte.

Und, klar, die Session-Handler sind da vielleicht ein Sonderfall. Aber session_write_close() und die Sache sollte gegessen sein...

Basti

[Byrel]

1. Warum installierst du dir nicht selber 5.2 und 5.1?
2. Weil ich soo unglaublich net bin habe ich mir 5.1 gezogen und kompiliert und mit beiden Versionen getestet.

Das ist das Script, dass angeblich funktionieren sollte.

<?php
function run_shutdown() {
global $x;
echo __FUNCTION__."\n";
$x->do_something();
}

class Foo {
function do_something() {
echo "hi\n";
}
function __destruct() {
echo __METHOD__."\n";
}
}

class Bar {

function __destruct() {
run_shutdown();
echo __METHOD__."\n";
}
}
$y = new Bar();
$x = new Foo();
?>

Ich bekomme sowohl mit 5.1 als auch mit 5.2 den gleichen Fatal Error. Deshalb ich mir das Script mal durchgelesen und es funktioniert wie folgt:

1. $y wird erzeugt (Typ Bar)
2. $x wird erzeugt (Typ Foo)
3. $x wird gelöscht
   1. Foo::__destruct wird aufgerufen
4. $y wir gelöscht
   1. Bar::__destruct wird aufgerufen
      1. run_shutdown wird aufgerufen
         1. run_shutdown versucht auf das Objekt $x zuzugreifen (dieses wurde aber schon zerstört)

$y = Objekt1
$x = Objekt2

Objekt1 wird erzeugt
Objekt2 wird erzeugt
Objekt2 wird zerstört
Objekt1 wird zerstört und versucht auf Objekt2 zuzugreifen. Das gibts aber leider nicht mehr

d.h.
Wenn es funktionieren würde, müsste ein Bug in PHP sein. Tauscht man aber einfach die Deklaration von $x und $y aus (also $x vor $y deklarieren) funktioniert alles perfekt - wie es sollte.

EDIT:
Versuch mal das Script von http://bugs.php.net/bug.php?id=36759. Sollte unter 5.2 als auch unter 5.1 das "Expected Result" ausgeben.

MfG Byrel

[dsxs]

Klar gibts bei dieses Beispiel einen Fehler, Byrel. Wäre tatsächlich schade, wenn dem nicht so wäre. Der Unterschied deines Bsps gegenüber meinem ist jedoch bloss, dass in deinem das Objekt 1 vom Objekt 2 abhängig ist - bei mir ist es andersrum...
Ich glaube aber, wir reden immer noch ein wenig nebeneinander her.

Ich versuche lediglich, den Ursprung des Fehlers, welcher beim Update meines Hosters auf PHP v. 5.2.0 aufgetreten ist zu finden. Ich kann es mir nicht anders erklären als dass die neue PHP Version scheinbar die Objekte andersherum zerstört.

Warum installierst du dir nicht selber 5.2 und 5.1?

So heftig interessiert's mich nicht, ich wollte mich bloss erkundigen, ob jemand anders dies bestätigen kann und ähnliches Verhalten bemerkt hat...


Danke Basti, mit session_write_close() sollte ich bei allen Versionen auf der sicheren Seite sein.

[marcel_m]

Hallo zusammen,

ich kann das Problem vollkommen nachvollziehen .... Ich konnte es nur übergangsweise so lösen, dass ich für die Funktion, die die Sessiondaten in die Datenbank schreibt eine neue Instanz des Datenbankobjets instanziiert habe ... das hat dann funktioniert...

Gruß Marcel