Warum ApplicationState in ASP.NET...

SliderMax

...wo 'static' Variablen doch das gleiche bewirken?
Wenn ich eine 'static' Variable vereinbare, so kann doch jeder Thread drauf zugreifen? Das funktioniert bei mir ohne Probleme.

Hat da jemand eine Erklärung?

Danke

gruß,

Slider

ASP.NET-Applikationen arbeiten doch etwas ganz anders als Lokale Applikationen
direkt auf Deinem Rechner. Auch wenn manches nicht so scheint.

Der Client stellt eine Anfrage an einen IIS irgendwo im Netz (Aufruf der ASP-Seite).

Dann sucht der IIS nach einem Modul in dem Fall dann nach einer DLL die durch
ein ASP.NET-Projekt auf den IIS gelangt. Nun wird diese DLL geladen und dortige
statische Variablen extra. Und irgendwann bekommt der Client dann einen Response, womit grundsätzlich die Aufgabe des IIS abgeschlossen ist. D.h. dieser bereinigt dann seinen Speicher und entlädt Module um einfach den Kopf/Speicher für andere Client-Request frei zu haben.
Wie lange die DLL und auch deren mögliche statische Variablen im Speicher gehalten werden liegt einzig und allein daran wie Session konfiguriert werden!

Zudem ist der Zugriff gerade auf solchen Speicher aus Gründen der Sicherheit
ein ganz anderer als bei einer simplen Consolen/GUI-Anwendung mit .NET! Denn ASP arbeite auf einem Server der übers Netzt mit vielleicht Dir kommuniziert.

Ich glaube es ist schon recht wenn statischer Speicher bei einem Webserver anders ghandhabt wird. Was ist wenn die Session unterbrochen wird der Server aber nix merkt, was passiert dann mit den statischen Variablen?

Also das sind mir jetzt die Gedanken die mir dazu einfallen. Ein gutes ASP.NET-Buch oder Tutorial gibt da bestimmt noch bessere Hinweise. Habe noch nicht viel mit ASP.NET gemacht, aber mir scheinen mögliche Problem plausibel durch manche meiner Überlegung. Muss nathürlich nicht ganz stimmen, man wird mich dann noch korrigieren.

Könnte möglich sein das es Konfigurationsmechanismen beim ASP.NET gibt wo man Sitzungen eines Client auch bezüglich des Speichers managen kann. Dies kann dann aber im Umkehrschluss Leistung/Sicherheit des IIS in Mitleidenschaft ziehen.

Was Du in normalen Anwendungen mit statischen Variablen lösen würdest braucht im Falle von ASP.NET um den Willen eines gut funktionierenten IIS besser eine ander Lösung. Und die gibt es auch da bin ich mir sicher.

mfg sclearscreen

P.S.: Wo ich mir bei ASP.NET ganz sicher bin ist das man die Möglichkeit hat
die Dauer zu bestimmen wie lange ein Modul der IIS für eine Sitzung im Speicher behält. Irgendwo mal ein Code in nem Buch gesehen.

Also ich würde meinen:

Sobald eine Applikation gestartet wird (erster User stellt Request), wird der aspnet_wp.exe (Worker Process) gestartet und für die Assembly eine AppDomain bereitgestellt. Das Framework verwaltet einen Thread-Pool. Jeder Thread erzeugt ein HttpApplication Objekt (ebenfalls gepoolt) und die Module (auch gepoolt). Dann wird der Handler aufgerufen und der Response erezugt.

Jeder Thread legt einen eignen Stack an, aber die statischen Variablen liegen im Daten-Speicherbereich der AppDomain und sind somit "threadübergreifend" definiert und leben über die gesamte Dauer der Applikation. Ich habe es getestet (z.B. mit einer Counter-Variablen, die pro Request um eins erhöht wird und auf die Seite geschrieben wird). Das funktioniert, als ob ich die Variable in das HttpApplicationState Objekt eingebettet hätte.