| Forum: ASP.NET |
Thema:
Re: Funktion zu bestimmten Tageszeiten aufrufen |
Von:
Klaus Holster (
05.05.2004 10:53) |
Der Zusammenhang der Komponenten ist in etwa folgender:
- Der IIS nimmt einen Request entgegen. Wenn er sich auf eine für ASP.NET registrierte Seite bezieht, wird der Request an einen ASP.NET Workerprozess weitergeleitet. Dieser stellt praktisch die ASP.NET Laufzeitumgebung dar. Er wird vom IIS verwaltet, und der IIS 6.0 hat dafür eine Reihe von Einstellmöglichkeiten: Unter anderem kann er den Workerprozess in regelmäßigen Intervallen prophylaktisch neu starten, was die Defaulteinstellung ist und gelegentlich zu Verwirrung führen kann. Sinnigerweise heißen die Workerprozesse im IIS "Application"
- Der Workerprozess verwaltet einen Pool von Application-Objekten. Er leitet den Request an eines dieser Application-Objekte weiter, das dann die Response-Seite erzeugt. Treffen während der Bearbeitung des ersten Requests weitere ein, so werden diese jeweils an eigene Application-Instanzen aus dem Pool weitergeleitet und jeweils in eigenen Threads bearbeitet. Mit diesem Mechanismus kann ASP.NET mehrere Seiten gleichzeitig bearbeiten.
- Application-Objekte können zur Laufzeit dynamisch erstellt und zerstört werden, je nachdem, wie der Server ausgelastet ist. Die Ereignisse Application.Start bzw. .End beziehen sich auf die Erstellung bzw. Zerstörung einer Instanz des Application-Objektes, nicht auf die Web-Anwendung insgesamt.
- Die Eigenschaften der Application-Objekte werden in der Global.asax definiert und können dort vom Entwickler beeinflusst werden.
- Innerhalb des ASP.NET Workerprozess gibt es unabhängig vom Application-Pool eine Datenstruktur vom Typ HttpApplicationState. Die heißt dummerweise auch "Application", ist aber etwas ganz anderes, nämlich ein Dictionary (wie die Session-Variable), in die man unter einem Key beliebige Objekte speichern kann.
- Der ApplicationState namens "Application" lebt unabhängig von den einzelnen Application-Instanzen aus dem Pool solange, wie der ASP.NET Workerprozess läuft. Das Application-Dictionary bildet damit den eigentlichen globalen Kontext der Webanwendung.
- Ein Objekt, das im Application-Dictionary enthalten ist, wird von der .NET CLR am Leben gehalten, selbst wenn das Application-Objekt(das aus dem Pool), in dessen Kontext es erzwugt wurde, längst wieder zerstört ist. Deshalb gehört die DB-Routine in das Application-Dictionary (und nicht in die Application, wie ich es in meinem ersten Beispiel fälschlicherweise gemacht hatte)
- Verwirrt ? Ich auch. Das ganze Konstrukt ist an sich sehr logisch aufgebaut und funktioniert auch wunderbar. Es ist aber wegen der Namensgebung nur durchschaubar, wenn man genau hinguckt. Die Application-Objekte aus dem Pool bilden eben nicht die Anwendung und die global.asax ist nicht so global wie der Name nahelegt. Und die Applications die der IIS verwaltet haben wiederum mit den Objekten, die sich "Application" nennen, nichts zu tun.
Klaus
| Betreff |
Von |
Datum |
|
|
|
|
G.
Guest
|
05.05.2004 15:24 |
|
|
|
Antworten
Vorsicht bei der Eingabe: Die Zeichen ' oder -- sind nicht erlaubt!
