Aufruf eines Programms von mehreren Anwendern

[Preissig]

Hallo!
Wenn meherere Anwender gleichzeitig eine Anwendung nutzen (z.B. ein Kontaktformular), wird dann das auf dem Server laufende Perl-Programm entsprechend oft im Hauptspeicher gehalten oder nur eine Version, die alle Anwender bedient?
Wie müßte dieses Programm dann gestaltet werden, damit es reentrant ist?

[Tom]

Hello,

Wenn meherere Anwender gleichzeitig eine Anwendung nutzen (z.B. ein Kontaktformular), wird dann das auf dem Server laufende Perl-Programm entsprechend oft im Hauptspeicher gehalten oder nur eine Version, die alle Anwender bedient?
Wie müßte dieses Programm dann gestaltet werden, damit es reentrant ist?

Es müsste

• getrennte Prozesse aufbauen         (tut es)
• unterschiedliche Sessions benutzen  (tut es)
• innerhalb einer Session für jeden Request einen eigenen Session-Var-Bereich aufbauen
    (dafür musst Du selber sorgen)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Preissig]

Es müsste

• getrennte Prozesse aufbauen         (tut es)

das Server-System?

• unterschiedliche Sessions benutzen  (tut es)

das Server-System?

• innerhalb einer Session für jeden Request einen eigenen Session-Var-Bereich aufbauen
    (dafür musst Du selber sorgen)

Das verstehe ich nicht. Ich habe mehrere formmailer angeschaut, u.a. den von SELFHTML, da habe ich nie was von Sessions gelesen.

[Struppi]

Wenn meherere Anwender gleichzeitig eine Anwendung nutzen (z.B. ein Kontaktformular), wird dann das auf dem Server laufende Perl-Programm entsprechend oft im Hauptspeicher gehalten oder nur eine Version, die alle Anwender bedient?

ja, nein.

Struppi.

[steckl]

Hi,

Wenn meherere Anwender gleichzeitig eine Anwendung nutzen (z.B. ein Kontaktformular), wird dann das auf dem Server laufende Perl-Programm entsprechend oft im Hauptspeicher gehalten oder nur eine Version, die alle Anwender bedient?

Bei jedem Aufruf eines Scripts (egal ob durch den gleichen Anwender oder durch unterschiedliche) wird ein neuer Prozess gestartet.
Dies sieht man deutlich, wenn man sich die Spezialvariable $$ mit der Prozess-ID anzeigen laesst.
Meine Erfahrungen beschraenken sich auf UNIX-Server, aber ich nehme mal an, dass es unter Windows auch nicht anders ist.

Wie müßte dieses Programm dann gestaltet werden, damit es reentrant ist?

Heisst das, dass das Script zweimal parallel aufgerufen werden koennen soll?
Das sollte eigentlich immer so sein nehme ich an, zumindest ist mir keine Ausnahme bekannt.
Ausser du schreibst irgendwelche Daten zum zwischenspeichern in ein File, dann musst du dieses File eben sperren, damit kein anderer Prozess das File veraendern kann, solange es noch gebraucht wird.

mfG,
steckl

[Tom]

Hello,

Heisst das, dass das Script zweimal parallel aufgerufen werden koennen soll?
Das sollte eigentlich immer so sein nehme ich an, zumindest ist mir keine Ausnahme bekannt.
Ausser du schreibst irgendwelche Daten zum zwischenspeichern in ein File, dann musst du dieses File eben sperren, damit kein anderer Prozess das File veraendern kann, solange es noch gebraucht wird.

Das geht nicht gut.
Jeder "Prozess" benötigt seinen eigenen Datenbereich. Das ist durch die unterschiedlichen Requests gewährleistet. Wenn man aber nun mit einer Session arbeitet (Zwischenspeicherung in einem File auf dem Server), dann muss man dafür sorgen, dass dieses File die Datenbereiche der unterschiedlichen Instanzen eines Dokumentes auch sauber voneinander trennt, bzw. sie sauber in eine Zeitschiene einordnet. Man unterscheidet hier nach _Vorgängen_.

Ein Vorgang in einem Client-Server-Wechselspiel kann aus beliebig vielen Request-Response-Paaren bestehen. Solange er nicht abgeschlossen ist, darf keine zweite Instanz des Vorganges unkontrolliert auf die Daten zugreifen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Siechfred]

Ein Vorgang in einem Client-Server-Wechselspiel kann aus beliebig vielen Request-Response-Paaren bestehen. Solange er nicht abgeschlossen ist, darf keine zweite Instanz des Vorganges unkontrolliert auf die Daten zugreifen.

Genau das hat setckl geschrieben, da er explizit auf Filelocking hingewiesen hat. Mich deucht, du denkst komplizierter, als es hier nötig ist :)

Siechfred

[Tom]

Hello,

Ein Vorgang in einem Client-Server-Wechselspiel kann aus beliebig vielen Request-Response-Paaren bestehen. Solange er nicht abgeschlossen ist, darf keine zweite Instanz des Vorganges unkontrolliert auf die Daten zugreifen.

Genau das hat setckl geschrieben, da er explizit auf Filelocking hingewiesen hat. Mich deucht, du denkst komplizierter, als es hier nötig ist :)

Nein, das hat er nicht geschrieben.
Und mich dünkt, dass Du "Vorgangsbearbeitung" und "Einzelrequest" durcheinanderbringst.

Das Sperren des Session-Files während des Requests reicht als Hilfsmittel gegen "Reentranz im HTTP" nicht aus. Da muss man den ganzen Vorgang absichern.

Außerdem muss ein Session-File auch gar nicht unbedingt vollständig gesperrt werden während eines Requests, sondern es würde reichen, es nur von Beginn der Lese- bis Ende der Schreiboperation zu sperren.

Wie man mit den Daten zu einem "Formular" innerhalb einer Session umgeht, liegt eben daran, ob man Reentranz zulassen will (also paralleles Abarbeiten gleichartiger Vorgänge) oder ob man sie zu verhindern versucht (Bsp.: Jeder Client darf nur einen Kunden zur gleichen Zeit bearbeiten...). Dann muss man durch Conflict-Counter das konkurrierende Verhalten abfangen und kann dann entscheiden, ob der Nachfolgeprozess (Vorgang) den Vorgänger ablösen soll (und der Vorgänger damit stirbt) oder ob man die Bearbeitung ablehnen will.

Leider weiß der Nachfolger nie, ob der Vorgänger noch lebt. Die Übernahme der Kontrolle durch den Nachfolger ist daher Standard. (Hinweis erfolgt natürlich vorher). Sollte der Vorgänger dann doch noch gelebt haben und nochmals zugreifen, erhält er eine Nachricht, dass der Vorgang bereits durch einen Nachfolger (fertig) bearbeitet wurde - uns tschüss.

(Da mein Artikel hierzu aber immer noch nicht fertig ist, kann ich auch nicht darauf verweisen)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[steckl]

Hi,

Ein Vorgang in einem Client-Server-Wechselspiel kann aus beliebig vielen Request-Response-Paaren bestehen. Solange er nicht abgeschlossen ist, darf keine zweite Instanz des Vorganges unkontrolliert auf die Daten zugreifen.

Genau das hat setckl geschrieben, da er explizit auf Filelocking hingewiesen hat. Mich deucht, du denkst komplizierter, als es hier nötig ist :)

Nein, das hat er nicht geschrieben.

Ich habe aber auch nichts von Sessions geschrieben.

Und mich dünkt, dass Du "Vorgangsbearbeitung" und "Einzelrequest" durcheinanderbringst.

Jeder Request bedeutet einen neuen Prozess auf dem Server. Man kann ja beispielsweise den Text vom Formmailer erst in ein Textfile schreiben und dessen Inhalt dann mit einem Mail-Tool verschicken. Dafür reicht ein einzelner Prozess aus und man brauch nicht zwingend eine Session. Wenn dieser Prozess das Textfile wieder freigiebt kann der nächste Prozess in das gleiche Textfile seinen Text schreiben.
Ob das sinnvoll ist ist wieder eine andere Frage.

Erst wenn das ganze komplexer wird braucht man Sessions.

mfG,
steckl

[Tom]

Hello,

Ich habe aber auch nichts von Sessions geschrieben.

Dann passt die Antwort aber auch nicht wirklich zur Frage, denn der OP wollte eindeutig Reentranz vermeiden. Diese muss man aber in einem verbindungslosen Protokoll etwas erweitert betrachten.
Das Sperren (Kontrollieren) von Datenzuständen nur während der Lebensdauer eines Prozesses reicht da nicht aus, weil bei HTTP Prozess <> Vorgang ist. Im Verbindungsorientierten Protokoll kann aber Prozess == Vorgang sein. Solange ein Prozess und seine Childs laufen, kann der betroffene Datenbereich gesperrt (oder markiert) bleiben.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[steckl]

Hi,

Ich habe aber auch nichts von Sessions geschrieben.

Dann passt die Antwort aber auch nicht wirklich zur Frage, denn der OP wollte eindeutig Reentranz vermeiden.

Der Begriff war neu für mich. Hab nur bei Wikipedia nachgelesen und da stand was von Prozessen.
Kann aber auch sein, dass ich es falsch interpretiert habe.

mfG,
steckl

[Tom]

Hello,

Der Begriff war neu für mich. Hab nur bei Wikipedia nachgelesen und da stand was von Prozessen.
Kann aber auch sein, dass ich es falsch interpretiert habe.

Wesentlich ist doch nur, dass der OP später keinen Datenmatsch erzeugt.
Wie weit er das Spiel treiben will, bleibt ja ihm überlassen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Preissig]

Könnte mir jemand das Ergebnis dieser Fachdiskussion übersetzen?
Was muß ich tun, um den in selfhtml vorgestellten formmailer so zu gestalten, dass es kein Kuddelmuddel gibt, wenn mehrere Personen nahezu gleichzeitig ein Formular abschicken. Dies ist durchaus wahrscheinlich bei gut besuchten Seiten.

[steckl]

Hi,

Könnte mir jemand das Ergebnis dieser Fachdiskussion übersetzen?
Was muß ich tun, um den in selfhtml vorgestellten formmailer so zu gestalten, dass es kein Kuddelmuddel gibt, wenn mehrere Personen nahezu gleichzeitig ein Formular abschicken. Dies ist durchaus wahrscheinlich bei gut besuchten Seiten.

Dazu musst du garnichts umstellen. Der Webserver erzeugt automatisch für jedes abgeschickte Formular einen neuen Prozess, der das Programm unabhängig von anderen Requests ausführt.

mfG,
steckl

[Preissig]

Dazu musst du garnichts umstellen. Der Webserver erzeugt automatisch für jedes abgeschickte Formular einen neuen Prozess, der das Programm unabhängig von anderen Requests ausführt.

Danke, dann bin ich beruhigt!

[Siechfred]

Danke, dann bin ich beruhigt!

Und ich glaube immer noch, dass Tom im vorliegenden Fall zu kompliziert gedacht hat ;)

Siechfred

[Tom]

Hello,

Und ich glaube immer noch, dass Tom im vorliegenden Fall zu kompliziert gedacht hat ;)

*mmmh*

Könnte aber auch sein, dass tatsächlich mal jemand diesen Thread liest, der "Formularverarbeitung" und "Vorgangsverarbeitung" so nutzen will, wie es richtig geht :-))

Nur für einen Formmailer mit nahezu Null Konsistenz- und Integritätsrisiko für den Datenbestand war die Betrachtung natürlich überskaliert.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Preissig]

Nur für einen Formmailer mit nahezu Null Konsistenz- und Integritätsrisiko für den Datenbestand war die Betrachtung natürlich überskaliert.

Heißt dies, dass steckls Aussage

"Dazu musst du garnichts umstellen. Der Webserver erzeugt automatisch für jedes abgeschickte Formular einen neuen Prozess, der das Programm unabhängig von anderen Requests ausführt."

falsch ist?

[Struppi]

Nur für einen Formmailer mit nahezu Null Konsistenz- und Integritätsrisiko für den Datenbestand war die Betrachtung natürlich überskaliert.
Heißt dies, dass steckls Aussage

"Dazu musst du garnichts umstellen. Der Webserver erzeugt automatisch für jedes abgeschickte Formular einen neuen Prozess, der das Programm unabhängig von anderen Requests ausführt."

falsch ist?

Wieso? Die Aussagen haben nichts miteineinader zu tun und stimmen beide.

Struppi.

[Siechfred]

Der Begriff war neu für mich.

Für mich in der Form auch, ich fand aber dies hier:
http://www.oreilly.de/german/freebooks/linuxdrive2ger/exblocking.html#EXREENTER

Siechfred