Problem mit ner Klasse, die sich beendet

[Le_Cheffe]

Hallo,

ohne Umwege zum Problem.

Ich habe eine Singleton Klasse, die verschiedene Methoden hat. Wenn ich die Klasse in der index.php instanziiere und z.B. den Login Screen aufrufe, dann sehe ich, dass sich die Klasse nach der Ausgabe des Bildschirm beendet (über "echo" in der _destruct Methode). Wenn ich nun die Daten im Login Screen eingegeben habe, dann wird erneut die index.php aufgerufen und hier kommt das Problem ... die Klasse wird erneut erstellt, da sie ja am Ende des Login Screens beendet/zerstört wurde.

Ist es möglich, die Klasse im Speicher zu behalten, so dass sie nur einmal erzeugt wird (sollte ja durch die Singleton Funktion möglich sein) oder ist das das normale Vorgehen von PHP ?

Gruß

Le Cheffe

[Le_Cheffe]

Keiner weiß eine Antwort ? *heul*

Dann versuche ich es mal etwas bildlicher zu beschreiben.

Ich habe ...

index.php

class a {

function start() {

   include("db.php");
   $x = datenbank_klasse::singleton();

   if ($page == 1) {
      $x->baue_seite1_auf();
   } elseif ($page == 2) {
      $x->baue_seite2_auf();
   }
   ....
   } else {
      $x->menu();
   }
   // und noch ein paar Sachen
}

}

/* AUFRUF */

$neu = new a(); 

In der Datei db.php sind halt die entsprechenden Datenbank- und Anzeige-Funktionen drin.
Wenn ich nun z.B. die Seite das erste Mal aufrufe, dann bekomme ich das Menü (FORM, die per Post geschickt wird) angezeigt. Wenn ich dann auf irgendeine Unterseite klicke, die per "SUBMIT" abschicke, dann lande ich ja wieder in der index.php, aber nun werden alle Klassen, sowohl a als auch datenbank_klasse neu instanziiert, ganz so, als ob sie nie dagewesen wären.

Meine Frage nun : Ist das das normale Vorgehen von PHP ?

Gruß

Le Cheffe

[asp2php]

Ja.

Aber Session, serialize/unserialize könnte dir helfen, achte auf Hinweise über __sleep und __wakeup

[Le_Cheffe]

Hi !

Ich danke vielmals. Das wollte ich nur hören. Auch danke für den Tipp mit der Session, die ich ja eh schon benutze, aber irgendwie nicht auf die Idee kam, mal für sowas zu "missbrauchen".

Gruß

Le Cheffe

[schlimmerfinger]

Ich würde es vermeiden zu grosse Klassen bzw. Objekte in einer Sessionvariable zu zuweisen. Da die Prefomence unter serialize/unserialize leiden könnte. Wenn es um eine presistente Datenbankverbindung geht, kann man das eh vergessen, da PHP die möglichkeit nicht bietet.

[Le_Cheffe]

Hi !

Es ging mir dabei eigentlich nur um eine private Variable in einer Klasse, die ich eigentlich auf jeder Unterseite eins hochzählen lassen wollte, um so nach dem "POST" sehen zu können, auf welcher Unterseite ich dann bin. Leider war der Wert dann immer weg, weil eben die Klasse weg war und wieder neu erzeugt wurde.

Kann du das mit den persistenten Datenbankverbindungen näher ausführen ? Benutze AdoDB und es scheint so, als ob persistente Verbindungen schon möglich wären. Lasse mich aber gerne eines anderen überzeugen.

Gruß

Le Cheffe

[schlimmerfinger]

Wenn es um ein Mehrseitiges Formular geht, würde ich dir empfehlen einen Blick auf HTML_QuickFrom_Controller zu werfen.

Mann kann in PHP keine Presistente Objekte, wie in JAVA oder Perl, speichern. Jedes Skript und damit alle Variablen, Fuktionen leben nur solange bis die Datei fertig geparst wurde, danach wird alles gelöscht.

Es gibt viele Quellen (und leider auch Programmierer), die generell empfehlen sog. "beständige Verbindungen" (persistent connections, pconnects) zum Datenbankserver aufzubauen. Der reguläre "connect()"-Befehl in PHP schliesst die Verbindung automagisch bei Beendigung des Skriptes, "pconnect()" tut genau dies nicht - die Verbindung bleibt bestehen.

In speziellen Einsatzgebieten - ein dedizierter Server mit einem (genau einem!) grossen Forum beispielsweise - kann das Sinn machen, weil die Verbindung beim Start des nächsten Skriptes nicht erneut aufgebaut werden muss, man spart so einige Millisekunden. Im Shared Hosting erzeugen pconnects aber ein grosses Ressourcen-Problem - sie sind nicht Skript-, sondern Webserverbezogen, und der Webserver ist für hunderte von Domains zuständig, die alle auf verschiedene Datenbanken zugreifen. Die Wahrscheinlichkeit, dass eine persistente Datenbankverbindung wieder genutzt werden kann ist ca. 1/(anzahl Präsenzen) (bei gleicher Lastverteilung) und tendiert somit stark gegen Null.
Gleichzeitig hält aber der MySQL-Server die Verbindungen bis zum Erreichen eines Inaktivitäts-Schwellenwertes offen und schwillt so sehr schnell auf ein vielfaches der tatsächlich benötigten Prozesse an.

Ein kleines Beispiel:

- Shared-Hosting-Server mit 100 Präsenzen (P)
- 20 Webserver-Instanzen (I) stehen zur Verfügung
- der pconnect-timeout auf dem SQL-Server beträgt 10 Minuten
- jede Präsenz hat 1 Besucher (B) pro Minute.
- jede zweite Präsenz nutzt pconnects
- nur jeder hundertste Aufruf kann den pconnect nutzen, wird in der Rechnung vernachlässigt

Das wären also 50 pconnects / minute, mithin immerhin 500 connections insgesamt. Für jede connection muss ein Prozess auf dem SQL-Server laufen. Nach 10 Minuten ist dann erstmal das Limit erreicht, die ältesten pconnects werden vom SQL-Server geschlossen. Die Prozesszahl pendelt sich also bei konstanten 500 ein.

Für die normalen Connects sieht die Rechnung wie folgt aus:

50 connects/minute, werden sofort wieder geschlossen, macht max. 50 Prozesse gleichzeitig, in der Praxis wesentlich weniger da gleichzeitiger Zugriff sehr selten ist.


Wie gesagt, pconnects können auf einem dedizierten Server sinnvoll sein, im Shared Hosting schaden sie nur extrem.

Cheers