MySQL über Webserver

[theo]

Mit FastCGI schon ... die Prozesse bleiben nämlich laufen.

Kann sein, damit kenne ich mich nicht aus. Aber die anderen Bedenken bleiben. Ich versuch's mal mit PHP.

[mschnell]

Darum geht's. Ausserdem sehe ich den Vorteil von CGI nicht. Das ist auch nur ein Prozess der nach Abarbeitung des Requests verschwindet. Die Datenbankverbindung lässt sich so auch nicht halten.

Wenn ich mich nicht täusche ist CGI die einzige Möglichkeit Informationen, die nicht direkt Datei-Inhalte sind über den http-Port eines Webservers (also auch durch den Webserver selber) zu tunneln. Bei "standard"-CGI ist das Programm beendet, bevor Daten an den Client geschickt werden. Das gilt vermutlich auch, wenn das CGI-Programm in PHP geschrieben ist. Wenn das Programm nicht beendet werdebn soll (also auch die Datenbank-Verbindung offen bleiben könnte) muss man in Linux "fast-CGI" (eine von Apache unterstützte Methode der Programm-Kommunikation über Pipes oder TCP/IP) oder in Windows ISAPI (eine vom IIS unterstützte Methode der Kommunikation mit einer DLL) verwenden.

Es ist denkbar, dass der PHP-Interpreter mit fast-CGI von Apache aufgerufen wird und somit (eine Zeit lang) laufen bleibt, wenn ein CGI-Request fertig bearbeitet ist. Keine Ahnung, wie sich das dann in einem PHP-Script verwenden lässt (z.B.Übergabe der offenen Datenbank-Verbindung von einem Request (=Start eines Scripts) zum nächsten.

-Michael

[mschnell]

Ich versuch's mal mit PHP.

Dann hoffen wir mal dass der PHP-Interpreter die dreckigen Details von CGI vor Dir verstecken kann .

-Michael

[theo]

Keine Ahnung, wie sich das dann in einem PHP-Script verwenden lässt (z.B.Übergabe der offenen Datenbank-Verbindung von einem Request (=Start eines Scripts) zum nächsten.

Ich hatte mir das angeschaut. Keine Chance.
Man kann die sog. PHP "resources" nicht in Session-Variablen speichern.
Das sind wahrsch. Pointer, die beim nächsten Aufruf ins Nirvana zeigen würden.

Code: Alles auswählen

resource mysql_query  ( string $Anfrage  [, resource $Verbindungs-Kennung   ] )

[mschnell]

Dann macht PHP wohl doch "normales" CGI und nicht "fast-CGI" .
-Michael

[Hitman]

Dann macht PHP wohl doch "normales" CGI und nicht "fast-CGI" .

Kann man so absolut nicht verallgemeinern. PHP bietet viele Schnittstellen - die Frage ist, was der jeweilige Server Administrator draus macht. Aber man kann sich quasi wieder nicht darauf verlassen, dass es überall genau gleich funktioniert.

[mschnell]

PHP bietet viele Schnittstellen

Wie meist Du das ?
(a) "das PHP Interpreter Executable kann über viele Schnittstellen mit einem Webserver kommunizieren" oder
(b) "die PHP-Sprache erlaubt es, viele Schnittstellen (zu was auch immer) zu programmieren" ?

zu (b): Wenn ich das richtig sehe sendet ein Programm in PHP-Sprache eine Information Richtung Client (also an den Webserver) mit "echo". Die verwendete Schnittstelle definiert - wie Du sagst - der Administrator des Webservers.

-Michael

[Socke]

Es gibt drei Möglichkeiten, PHP auf einem Webserver einzusetzen:

• als Server-Modul (nur Apache, bessere Performance, aber sicherheitskritisch)
• als CGI (der PHP-Interpreter wird als CGI gestartet)
• als Fast-CGI (als Erweiterung von CGI)

zu (b): Wenn ich das richtig sehe sendet ein Programm in PHP-Sprache eine Information Richtung Client (also an den Webserver) mit "echo". Die verwendete Schnittstelle definiert .- wie Du sagst - der Administrator des Webservers.

Allen gemeinsam ist, dass die Ausgabe (stdout) des Programms (PHP-Interpreter/-Modul/CGI) als Rückgabe des Webservers herhalten muss (als ob es eine Datei wäre). Wie die Anbindung von PHP an den Server geschieht ist Sache des Administrators und sollte die PHP-Scripte nicht wesentlich beeinflussen (unter normalen Umständen).
Daten direkt an den Client senden, kann nur der Webserver (dieser ist für die Verbindung zuständig -> ansonsten hat man einen eigenen Server).

[mse]

Ich hab mal gesucht und ein PHP Script gefunden, was SQL-Queries entgegenimmt und XML Daten zurückliefert.
Das funzt soweit, ist aber natürlich nicht das Gelbe vom Ei, weil man alles manuell machen muss.
Es gibt wohl keine TMySQLXMLWebConnection oder sowas, damit man die Data Controls oder TSQLQuery etc. verwenden könnte, stimmt's?

Das sollte mit einem tcustomsqlconnection Nachkommen machbar sein, ich beziehe mich hier auf die MSEgui Version:
- internalexecute() reicht den SQL-Text an das PHP-Script weiter.
- Der Server liefert XML zurück, die connection Komponente decodiert und speichert die Daten.
- fetch() und loadfield() liefern die Daten an tsqlquery.

Das in einem anderen thread aufgetauchte Problem der Server generierten IDs bei INSERT löst MSEgui bei MySQL durch Zurückschreiben der LastInsertID in das primary key field.
Neu gibt es auch ein pf1_refresh flag in der tmse*field providerflag1 property welche RETURNING bei INSERT und UPDATE verwendet um auf die Server generierten Werte zu synchronisieren.

[mschnell]

Es gibt drei Möglichkeiten, PHP auf einem Webserver einzusetzen:

• als Server-Modul (nur Apache, bessere Performance, aber sicherheitskritisch)
• als CGI (der PHP-Interpreter wird als CGI gestartet)
• als Fast-CGI (als Erweiterung von CGI)

Das ist alles Linux. In Windows mit ISS - da gibts kein fast-CGI - sollte doch auch ISAPI möglich sein (das ist so was ähnliches wie Apache Server-Modul) ....

Allen gemeinsam ist, dass die Ausgabe (stdout) des Programms (PHP-Interpreter/-Modul/CGI) als Rückgabe des Webservers herhalten muss

Nö. Fast-CGI verwendet eine Pipe oder TCP/IP zwischen dem Webserver und dem CGI-Programm in beiden Richtungen. Was ISAPI verwendet, weiß ich nicht, jedenfalls nicht STDOUT. Normales CGI in Windows verwendet aber auch STDOUT.

-Michael