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

[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

 

[Anthony Jones]

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?

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?

 

[sloan]

What does
"establish some
database-connections"
mean?

Are you persisting them somewhere? If so, bad approach, esp in the asp.net
world.

 

[Patrick Sona]

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?

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

 

[John Rivers]

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

 

[Anthony Jones]

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.

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?

 

[Patrick Sona]

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?

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

 

[Patrick Sona]

What does
"establish some
database-connections"
mean?

Are you persisting them somewhere? If so, bad approach, esp in the asp.net
world.

It means a connection to an ActiveDirectory and establish a cache for
frequently accessed objects of this AD.

 

[Anthony Jones]

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?

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.

 

[John Rivers]

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