How to force an ASP.NET web-application to exit

  • Thread starter Thread starter Patrick Sona
  • Start date Start date
P

Patrick Sona

Hi all,

Is it possible to force an ASP.NET web-application to exit?
At application-startup I have to check and establish some
database-connections. If there an error occours, the application must
shutdown, so that at the next request the application_start section will
be reentered.

Has anyone a solution?

Greetings
Pat
 
Patrick Sona said:
Hi all,

Is it possible to force an ASP.NET web-application to exit?
At application-startup I have to check and establish some
database-connections. If there an error occours, the application must
shutdown, so that at the next request the application_start section will
be reentered.

Has anyone a solution?
Click to expand...

HttpRuntime.UnloadAppDomain() would do it.

Just to be sure the Database connections are unusual ones that can't benefit
from standard pooling techniques?

Are you sure you need such a drastic response?
 
What does
"establish some
database-connections"
mean?

Are you persisting them somewhere? If so, bad approach, esp in the asp.net
world.
 
Anthony said:
HttpRuntime.UnloadAppDomain() would do it.

Just to be sure the Database connections are unusual ones that can't benefit
from standard pooling techniques?

Are you sure you need such a drastic response?
Click to expand...
Thanx for the quick response!
There are also some objects, which must be initialized at startup. If
there occures an error, (which should normaly not happen), then other
objects could't initialized and the application will be crash.

Thanx a lot!
Greetings
pat
 
your init should not be in the application startup code

as it needs to be called at other times

move the init code into a method
that inits and then sets a flag
if flag is set it does not init
now you can reset at will
 
Patrick Sona said:
Thanx for the quick response!
There are also some objects, which must be initialized at startup. If
there occures an error, (which should normaly not happen), then other
objects could't initialized and the application will be crash.
Click to expand...

As John says doing this in the App start is probably not a good idea.

Sounds like what you need is to encase the dependant objects needed into a
'lazy' singleton pattern.

All access to the containing object is via a Static property on the object
that will instance on demand.

See: http://www.yoda.arachsys.com/csharp/singleton.html

BTW, you're happy you've got thread-safety sorted?
 
Anthony said:
As John says doing this in the App start is probably not a good idea.

Sounds like what you need is to encase the dependant objects needed into a
'lazy' singleton pattern.

All access to the containing object is via a Static property on the object
that will instance on demand.

See: http://www.yoda.arachsys.com/csharp/singleton.html

BTW, you're happy you've got thread-safety sorted?
Click to expand...
Thanx John and Anthony!

In normal case a singelton would be the best solution. But the objects
must be accessable from all sessions and should only be initialized at
one time. So if I realize it with the singelton-pattern, the problem is,
that each session creates its own instance. Or is that a wrong oppinion?

So my idea was, that all objects which must be have an
application-global scope are initialized at the beginning and stored in
the applicationstore.

Have you a better solution?
Greetings
Pat
 
sloan said:
What does
"establish some
database-connections"
mean?

Are you persisting them somewhere? If so, bad approach, esp in the asp.net
world.
Click to expand...
It means a connection to an ActiveDirectory and establish a cache for
frequently accessed objects of this AD.
 
Patrick Sona said:
Thanx John and Anthony!

In normal case a singelton would be the best solution. But the objects
must be accessable from all sessions and should only be initialized at
one time. So if I realize it with the singelton-pattern, the problem is,
that each session creates its own instance. Or is that a wrong oppinion?
Click to expand...

Yes its wrong. The singleton pattern will create only one object across the
whole application (the AppDomain). That why I asked you about thread
safety, its actually tricky stuff that comes as a bit of a surprise,
especially to former ASPers making the transition to ASP.NET.
 
Having only one instance will cause locking bottlenecks

Having one instance per session will likely cause excess resource
usage

I would consider using a small pool of connections

the application level lock only needs to last long enough to decide
which connection to use for the current thread

you can make it self tuning - if all connections are in use increase
the pool size
the pool which automatically reach the ideal size for performance
 
Back
Top