IHttpModule Question (storing state)

[Mike]

I've created a custom IHttpModule that does custom authentication.
Currently it stores authenticated user info in a hashtable within the
class so I don't have to re-authenticate against a database everytime a
logged in user hits a page.

So far, it works great.

Here is my question, is my approach for storing logged in users
correct? Meaning, can I be sure that only one instance of my
IHttpModule will be created for my Application. So far, in testing,
this seems to be the case, but I have yet to do any hardcore multiuser
testing. If more than one instance is created, my method of storing
logged in users will fail because each instance will have its own
hashtable.

So if that is the case, I figure I'll make the hashtable static. Does
anyone see any downside to this?
Thanks for your help

[Brock Allen]

There will be many instances of your HttpModule withint the application.
ASP.NET creates and maintains a pool of HttpApplication/HttpModules tuples
for servicing requests when the arrives in ASP.NET. So any one instance of
your HttpModule will be thread safe, but shared data won't be. Also, if you
want to cache/share data among them then static variables are an option,
but so is the ASP.NET data Cache. The first part of this article talks about
threading and the app/modules pooled in the HttpPipeline:

http://msdn.microsoft.com/msdnmag/is...g/default.aspx

-Brock
DevelopMentor
http://staff.develop.com/ballen

I've created a custom IHttpModule that does custom authentication.
Currently it stores authenticated user info in a hashtable within the
class so I don't have to re-authenticate against a database everytime
a logged in user hits a page.

So far, it works great.

Here is my question, is my approach for storing logged in users
correct? Meaning, can I be sure that only one instance of my
IHttpModule will be created for my Application. So far, in testing,
this seems to be the case, but I have yet to do any hardcore multiuser
testing. If more than one instance is created, my method of storing
logged in users will fail because each instance will have its own
hashtable.

So if that is the case, I figure I'll make the hashtable static. Does
anyone see any downside to this?

Thanks for your help

[Matt Berther]

Hello Mike,

I think you do have to make it static. I believe that if you put a ctor on
your on your HttpModule, you'll see that its recreated.

--
Matt Berther
http://www.mattberther.com

I've created a custom IHttpModule that does custom authentication.
Currently it stores authenticated user info in a hashtable within the
class so I don't have to re-authenticate against a database everytime
a logged in user hits a page.

So far, it works great.

Here is my question, is my approach for storing logged in users
correct? Meaning, can I be sure that only one instance of my
IHttpModule will be created for my Application. So far, in testing,
this seems to be the case, but I have yet to do any hardcore multiuser
testing. If more than one instance is created, my method of storing
logged in users will fail because each instance will have its own
hashtable.

So if that is the case, I figure I'll make the hashtable static. Does
anyone see any downside to this?

Thanks for your help

[Mike]

Brock,

Thanks for the reply. I'd like to use built in ASP.NET cache, but
since I am doing my processing in the AuthenticateReq uest event, I was
under the impression that built in session and other caching mechinisms
are not available. Is this correct?

[Brock Allen]

The data Cache is different from Session. You're right that in the AuthenticateReq uest
event Session is not yet available, but the data Cache is. I'd use the data
Cache.

-Brock
DevelopMentor
http://staff.develop.com/ballen

Brock,

Thanks for the reply. I'd like to use built in ASP.NET cache, but
since I am doing my processing in the AuthenticateReq uest event, I
was under the impression that built in session and other caching
mechinisms are not available. Is this correct?