|
 Thursday, March 01, 2007 |
| Be careful when using a Public Module in ASP.NET |
|
I recently came across a rather disturbing issue while using a Public Module in ASP.NET. I had created a Public Module like:
Public Module MyModule
‘Some code here
End Module
I was using the Public Module to build unique connection strings for users based on their login name. The idea here was that each user would have their own database and would be accessing their own data when they logged in. I had put the code in a Public Module for easy reuse, thinking that each user’s session would be using its own instance of the Module. When the user logged in, it would build the connection string for that user and store it in a variable. The next time they accessed the Module, it would see if the connection string had already been built.
What I discovered is that any Public Modules are actually application level not session level. This meant that if User A logged in and the connection string was build for User A’s database, and then User B logged in after words, it would change the stored connection string in the Public Module, and the next time User A executed an action that needed data from the database, it would try to use the database for User B. Go ahead and read it again if you need to.
Fortunately the way the code was written; this scenario just caused an error. However, it took me a bit to figure out what was going on. I can’t believe I didn’t know that a Public Module was application level after all my experience and all my studying for my MCP Cert. I’m still kicking myself.
I fixed the issue by using a session variable to cart around the connection string for each user and did away with using the Public Module. I can see there could be some good uses for the Public Module now that I know it works that way. |
jeremy at 3:30 PM |
(3) Comments |
Add a comment |
Permalink
|
|
|
|