The hard part with this idea is you are trying to capture an application
from within an application and then have it reset itself. It might be
possible to destroy the app from within the app, but that would likely throw
its own error. You could possibly climb up the stack and cause the aspnet
worker process to kill the application, but that could error, as well.
To capture outside of the stack, you could use an HTTP Handler, but the
handler would have to test and throw or engage some form of app watcher. If
you are testing the SQL conn anyway, it makes more sense, to me, to go the
path of least resistance and test the connection before trying to set it, or
try ... catching it and setting an app variable so the person cannot hit
anything if the SQL conn is hosed. To make sure this scenario "reboots" when
available, it is best to use Session_Start, as every session start will hit
the site and run the code. If you do it as a Singleton, you will only
instantiate once, which is far less intrusive for application level code.
The cleanest I can think of is something like this:
public class Singleton
{
private Singleton()
{
'Code here that sets up app variables that might fail
'(or call routine)
}
private static Singleton _single;
public static GetSingleton()
{
if (_single == null)
_single = new Singleton();
return _single;
}
}
To call
Session_Start()
{
'Test things that might fail
if(noFailingCon ditions)
{
'You can use this anywhere in code an it always returns the same one
Singleton single = Singleton.GetSi ngleton();
'Code here to do stuff that is in the Singleton
}
}
I think this is pretty straightforward . In addition, it sets you up for
success and not failure. And, it does not require climbing all the way
outside of your app domain to control your app domain.
An even better model is to set up the protection code in the Singleton and
have check routines on the Singleton that retry broken bits. In this manner,
you do not have to restart applications due to failure, as the app becomes
somewhat self-healing.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************** *************** ***************
Think outside the box!
*************** *************** ***************
"masmith" <ma*****@discus sions.microsoft .comwrote in message
news:F5******** *************** ***********@mic rosoft.com...
>I was hoping for something cleaner and simpler, such as resetting the
application. Instead I have the code executing the startup code in the
Applcation_Star t and in the Session_Start if an Application["ErrMsg"] in
not
null. If any errors are found initializing the Application objects or
starting the SQLDependency, I set the Application["ErrMsg"] to a
appropriate
string for the error.
--
Mark
"Cowboy (Gregory A. Beamer)" wrote:
>Perhaps with an HTTP Handler, but this is a lot of overkill for something
you can catch and avoid. Move the code that occasionally errors to the
SEssion_Star t and set it up as a singleton, so it does not have to run
over
and over again when everything is correct. You then get the best of both
worlds.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
************** *************** *************** *
Think outside the box!
************** *************** *************** *
"masmith" <ma*****@discus sions.microsoft .comwrote in message
news:09******* *************** ************@mi crosoft.com...
Can you restart an ASP.NET application in the Application_Sta rt event
when
an
error occurs so the next request for the application will fire the
Application_Sta rt event again?
This would allow the application to recover without intervention if the
problem is a database server is temporarily offline or other external
source
of data being loaded in the Application_Sta rt event having a problem.
I
usually set up a SQL Dependency in the Application_Sta rt event and get
data
that changes infrequently. I need this initialization to occur even
when
previous page requests failed and the database server is available
again.
I
would also like it to display an error message to let the page
requestor
know
there is a problem and to exit and reopen IE and retry the page in a
few
minutes.
--
Thanks,
Mark
