GlobalContext problem with ASP.NET 2.0

tymberwyld posted on Thursday, January 04, 2007

While running an ASP.NET 2.0 application, I am having a problem with "static" variables in classes. I have some objects that implement a static constructor that initializes some information on a per-type basis. However, these static constructors / methods never get called again unless the web app is restarted.

One of the things I need to do is support multiple database connections. I've been able to do this by extending the "DataPortalContext" class. I added a property in the ApplicationContext class called "DataPortalContext". This property actually is read / write from the GlobalContext collection. So, for example, I have a "defaultConnection" and a "authConnection" in the GlobalContext collection that are both of type "DataPortalContext". I switch between the two of these in certain business objects so be able to retireve the data from the correct database when methods on the DataPortal are called. The DataPortal has been extended some to build a connectionstring from the ApplicationContext.DataPortalContext.

Long story short, everything would be nice except that when the web app is run subsequent times, the GlobalContext objects are cleared and along with the fact that the static constructors are never called again, the DataPortal crashes on subsequent calls to the database.

I am looking for suggestions for storing the GlobalContext in something more...well...Global? Instead of just using the HttpContext.Current, isn't there something more that ASP.NET can use to be global to ALL sessions?

RockfordLhotka replied on Thursday, January 04, 2007

Nothing in Csla.ApplicationContext is designed for the purpose you describe. Within the context of a web application, all three collections (GlobalContext, LocalContext, ClientContext) exist only for the lifetime of the current page request.

If you want per-user data that spans multiple page requests, then use Session.

If you want per-app data that spans multiple page requests (and users), then use Application, or use a static field that is global in scope. As you note, static constructors are called once. But also, static fields are available globally to all users of the web app (on that web server).

One exception - static fields in an aspx page are automatically serialized to/from ViewState - so be careful with that, because that can blow out the size of your page!! Also those fields are then per-user, not per-site like you'd expect.

tymberwyld replied on Thursday, January 04, 2007

Ok, I guess that makes sense. Currently, I am just calling a method in the classes that need to switch the DataPortalContext and checking to see if the context I am looking for exists in the GlobalContext, if not, it re-creates it. I guess this is fine, it's not too much work.

I really don't want to clutter up the ApplicationContext, but since I did put a DataPortalContext property in it, do you think it would be better to just make this property come from a static field instead of the GlobalContext? I'm thinking no because if this makes it so that multiple users will have the same instance, then there could be an issue where the DataPortalContext is set temporarily to a different database and either returns the wrong data or just gives a Sql error.

Thanks.