[Python-de] letzte Rettung

Ralf Geschke ralf at kuerbis.org
Thu May 10 16:00:09 EDT 2001


> 
> Und was genau ist dein Problem? Wenn der Interpreter persistent
> ist, dann koennen grundsaetzlich auch alle anderen Teile einer
> darin ausgefuehrten Applikation persistent sein. Das schliesst
> ohne weitere Zauberei auch Datenbankverbindungen mit ein.

Eigentlich habe ich kein Problem. Du kannst Deine Behauptung
gerne beweisen, wie erwaehnt, im mod_python-Manual ist mir
keine einzige Stelle untergekommen, die sich der Persistenz
gewidmet haette. Und dass diese ohne weitere Zauberei 
per se vorhanden ist, glaube ich nun wiederum nicht. 

> > Ja schon, aber wie haeufig wird denn das Skript in den Interpreter
> > geladen?
> 
> Einmal.

Bist Du sicher?

> Da fehlt dir offenbar das grundlegende Verstaendnis, wie bei
> Python Module behandelt werden. Ein Modul kann zwar viele male
> "import"iert werden, physisch geladen wird es aber nur beim
> ersten mal. Jedes weitere import-Statement liefert einfach das
> schon geladene Modul zurueck. Aller eventuell verhandener
> Initialisierungcode (z.B. das Oeffnen einer Datenbankverbindung)
> wird ausschliesslich beim ersten mal ausgefuehrt.

Das heisst: Beim ersten Aufruf einer stand-alone-kommandozeilen-Applikation
werden _einmal_ die Module geladen (importiert). Wenn das Programm
danach beendet und neu gestartet wird, werden die Module
_nicht_ wieder neu geladen? Sie bleiben (irgendwo) im Interpreter
stecken?
Meinst Du das im Ernst?

Etwas anderes ist doch eine Web-Applikation nun wirklich nicht: 
User sendet Request, Request wird von Python abgearbeitet,
Skript beendet sich, User sieht HTML im Brauser. 

Oder bei CGI-Skripten, die in Python geschrieben werden? 
Ist hier das Verhalten genauso wie von Dir beschrieben?
Die Skripte sind doch irgendwann einmal abgelaufen und 
werden beendet (noch ist HTTP ein statusloses Protokoll, auch
Python kann daran nichts aendern...). 

Was also ist bei mod_python anders als bei Python-CGI-Skripten,
ausser dass der Python-Interpreter direkt im Apache steckt?
(Und dass noch ein paar zusaetzliche Module bereitgestellt werden,
die aber allesamt nicht mit der Persistenz zusammenhaengen,
zumindest konnte ich auf der Web-Site von mod_python nichts finden).

> Das obige Beispiel illustriert genau dieses Prinzip, und
> beantwortet deine urspruengliche Frage damit schon vollstaendig
> und erschoepfend. Es handelt sich bei diesem Code-Beispiel um den
> (unvollstaendig implementierten) Prototypen eines kompletten
> Application-Servers. Genau das, was du haben willst! Viel
> komplizierter muss es gar nicht mehr werden.

Das ist kein Application Server. Wirklich nicht...

> Das ist nicht die Aufgabe von mod_python. Mod_python stellt
> sicher, dass der Python-Interpreter geladen wird und bleibt,
> und dass die richtigen Handler aufgerufen werden. Die konkrete
> Datenbankverbindung wird ein paar Ebenen weiter hinten von einem
> reinen Python-Modul aufgebaut und unterhalten.

Aha. Nun widersprichst Du Dir selbst ein wenig. Also Aufgabe vom
Python-Datenbank-Modul. Gut. Und das kennt persistente Verbindungen?
Selbstverstaendlich bleiben die Verbindungen offen bei einer
_laufenden_ Anwendung. Aber wenn diese beendet worden ist, 
duerften sie geschlossen werden, oder? 

> > Keine Persistenz (ausser bei Datenbankverbindungen, ist somit eine
> > Spezialitaet von mod_php), kein Connection Pooling, keine
> > Hintergrundprozesse...
> 
> Und was hat das alles miteinander zu tun?

Alles Merkmale eines Application Servers. 

> Falls PHP auf der Sprachebene keine persistenten Module (und damit
> Modulattribute wie Datenbankverbindungen) zulassen sollte, dann
> ist das eben nicht das gleiche. Da dies bei Python der Fall ist,
> muss nicht das Apache-Modul fuer andere Zwecke als die Koppelung
> zum Web-Server "missbraucht" werden.

Ich habe das Gefuehl, Du willst gar nicht versuchen, mich zu verstehen. 

> Das Connection-Pooling hat mit dem Applikations-Server meines
> Erachtens ueberhaupt nichts zu tun (das passiert einige Ebenen
> weiter vorne), und Hintergrundprozesse brauchst du nur dann, wenn
> dein Applikationsserver nicht in der Lage ist, die ganze
> Applikation selber abzuwickeln. Ein Spezialfall eines solchen
> Hintergrundprozesses ist natuerlich die Datenbank selber, die
> *muss* aber auch nicht seperat sein (siehe z.B. Zope)!

Was meinst Du mit "die ganze Applikation selber abzuwickeln"?
Etwa, dass die Anwendung rein request-gesteuert ablaeuft? 

Dies ist doch der klassische Ablauf von CGI-Skripten, oder
auch PHP-Skripten: Auf dem Server geschieht nur bei einem
Request etwas (etwa Datenbank-Abfrage). Genaugenommen ist
dies sprachenunabhaengig, und ich behaupte, dass auch mod_python
nichts anderes macht, weshalb es auch keinen Application Server
darstellt. 

Ob man eine Datenbank als Application Server bezeichnen moechte,
nunja, darueber kann man sicherlich streiten, ich wuerde 
sie nicht so nennen. 

Jegliche Beweise der Persistenz innerhalb mod_python-Anwendungen
nehme ich nach wie vor gerne entgegen. 

Beste Gruesse,
   Ralf



More information about the Python-de mailing list