+972 52-548-6969
Solving the HttpModule mess
time to read 2 min | 222 words
Okay, I think that I managed to dechiper most of the strange behavior in ASP.Net's Http Modules.
Or, more correctly, you can't rely on unsetting a static varaible in Dispose() and setting it in Init() (or Application_Start and Application_End), since they may be called several times.
This mean that you either have to do a ref counting ( Bad ), or implement application level variables in Web secanrios. (Or just forgo about cleaning resources when the HttpApplication is going down).
I chose the first way, but it is not very clean, in my opion, check out the changes that I had to make:
Basically, this means that when running under Web context, it will use the current application as a global variable, and when running under non-web context, it will use a static variable.
- An AppDomain may hold zero or more instances of HttpApplication
- A new instance of HttpApplication may be created (for reasons that I have not been able to figure out) - a set of all the http modules will be created as well.
- An instnace of HttpApplication may be disposed (with its associted http modules) at any time.
- A request will always be served by a fully initialized HttpApplication.
Or, more correctly, you can't rely on unsetting a static varaible in Dispose() and setting it in Init() (or Application_Start and Application_End), since they may be called several times.
This mean that you either have to do a ref counting ( Bad ), or implement application level variables in Web secanrios. (Or just forgo about cleaning resources when the HttpApplication is going down).
I chose the first way, but it is not very clean, in my opion, check out the changes that I had to make:
Basically, this means that when running under Web context, it will use the current application as a global variable, and when running under non-web context, it will use a static variable.
Comments
Comment preview