Das hier hätte ich beinahe überlesen:
Zitat:
...alles in
eine ISAPI packst?!
Und dabei war das (zumindest für mich) das Wichtigste.
Eine Webbrokeranwendung (
Isapi) wird genau für jeweils einen Request ausgeführt, beantwortet diesen und wird dann beendet. Man kann das Webmodul zwar auch deaktivieren - es ist dann einfach 'geparkt' und kann bei Bedarf wieder aktiviert werden. Aber sie eignet sich nicht für ein Session-oder Cookie-Managment.
Nö. Wenn die
ISAPI einmal geladen ist, verbleibt sie normalerweise im Speicher; es sei denn du setzt absichtlich den Registryeintrag "CacheExtensions" auf 0:
http://msdn.microsoft.com/de-de/libr...(v=vs.71).aspx
Aber davon wird explizit abgeraten, außer zum Debuggen.
Mit UniGui (unigui.com) kann man auch eine
ISAPI-
DLL erstellen und die ist "statefull" (hält also Daten für jede aktive Session im Speicher)!
Und eine Session in die
DB zu schreiben, solange sie nicht beendet wird, denke ich, sollte im Interesse der Performance wohl besser unterbleiben. Ich denke, das ergibt viel zu viele Datenbankzugriffe, vor allem, wenn ich auch anonyme Zugriffe über Sessions ablaufen.
Du kannst die Daten auch im Speicher behalten, musst aber ein paar Dinge beachten:
Globale Variablen sind grundsätzlich Pfui, da
multithreaded, und müssen durch critical sections abgesichert werden. Aber als globale Variable brauchst du eigentlich nur eine SessionList (Liste, Array, Hashmap, ...). Diese ist durch eine CriticalSection abzusichern.
In die einzelnen Sessions (Session-Objekte) kannst du dann deine Daten, (Daten-)Objekte, Datenmodule etc. packen. Dabei muss ein Objekt oder Datenmodul für jede Session neu erstellt werden und es dürfen auch dort keine globalen Variablen, sondern nur Felder/Properties verwendet werden.
Gruß
Olli