ASP.NET Custom Application Quiescing

Hi,

Anybody know how to do Quiescing  in ASP.NET custom applications?Quiescing refers to blocking all new ASP.NET Request and still continue processing existing requests until it ends. I need such functionality to be aible to do backup and archival online through an administrator module.I dont want existing users to be affected when the administrator start the backup and archival module. I know Windows SharePoint Services has such an ability.

i don't think ASP.NET has that capability built in (well it has the offline feature but then all active sessions would suddenly go pfft)

i suggest you have something like an application variable indicating if the app is in quiescing mode. then have the checking for it done in the session_start event handler in your global.asax. that way, new users/sessions going into your site would be blocked, but existing users will still be served until they finish their stuff.

I think this might work. thanks for your reply

i forgot to mention (though i'm sure you've realised) that there has to be a way to set that application variable...it can be part of the web app itself (that's accessible only to admin role users)

The existence of the Application object (and variables) is for backward compatibility and not recommended for use in ASP.NET.

http://quickstarts.asp.net/QuickStartv20/aspnet/doc/applications/default.aspx

It is simpler to use static variable in a custom class to mark if a particular process is already underway. If you want to make it a more "formal" mechanism, using a Stack object that only allows one item to be pushed in can be done. The thread/request that made the push can then pop it after it is done. You'd have to take care of errors that may prevent proper popping of the Stack.

thanks for pointing that out icelava -- you can use static vars in a class and use it application-wide too. however I know of no significant disadvantage (e.g. performance) when using the Application store -- other than it not being strongly typed (that's the only disadvantage i can think of). thus, using a bool for it (to indicate the app's quiescing state) would require boxing/unboxing, hence, the need for additional code to do type casting. in this particular case, race conditions wouldn't probably be much of a concern, since it's likely that only one user (the admin) would be triggering the quiescing state, and all other accesses to that variable -- whether via static var in a class or Application store -- will be read-only.

In real-world statistics, there is a slight performance advantage. Your mileage may vary.

I have read somewhere that the HttpApplicationState object, in order to be backward compatible with [classic] ASP, implements a threading model (STA?) that may hurt the nature of .NET multithreading. I cannot find that material anymore, and it does not make sense to me that it should remain STA in a default .NET world. I think that only happens when AspCompat is set to True.

then it looks like storing the data in some static member of a class does make better sense