Application_OnStart event

[Marek]

Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[Alvin Bruney [MVP]]

No such guarantee is made. I think there is some confusion in the question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets paired
with an httpapplication instance. If the httpruntime could only respond to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the request
can be associated with only one httpapplciation object.

 

[Marek]

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization in
this handler
(such as reading config files, remote configuration to name a few). However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could you
explain where I'm making
a mistake?

Marek

No such guarantee is made. I think there is some confusion in the question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets paired
with an httpapplication instance. If the httpruntime could only respond to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[Alvin Bruney [MVP]]

The framework guarantees that, regardless of concurrent requests, the
application object will be initialized only once per application domain.
This happens when the first request is received. If two requests are
received at the same time, the runtime uses a spin-lock to force one request
to wait while the other is serviced guaranteeing threadsafety.

Now, once that initialization has occurred, its an open field where thread
access/concurrency is concerned so care must be taken for objects with
global scope in the application object. Good question. I had to think about
this for a while.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization
in
this handler
(such as reading config files, remote configuration to name a few).
However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could you
explain where I'm making
a mistake?

Marek

No such guarantee is made. I think there is some confusion in the
question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is
serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets
paired
with an httpapplication instance. If the httpruntime could only respond
to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the
request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[Marek]

Thank you. Where could I read more about it?

The framework guarantees that, regardless of concurrent requests, the
application object will be initialized only once per application domain.
This happens when the first request is received. If two requests are
received at the same time, the runtime uses a spin-lock to force one request
to wait while the other is serviced guaranteeing threadsafety.

Now, once that initialization has occurred, its an open field where thread
access/concurrency is concerned so care must be taken for objects with
global scope in the application object. Good question. I had to think about
this for a while.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization
in
this handler
(such as reading config files, remote configuration to name a few).
However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could you
explain where I'm making
a mistake?

Marek

No such guarantee is made. I think there is some confusion in the
question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is
serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets
paired
with an httpapplication instance. If the httpruntime could only respond
to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the
request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[DalePres]

The solution to the problem is to lock the application object early in the
code of your Application_OnStart with a call to Application.Lock(). This
will make sure that any other calls are blocked until you complete your
initialization.

Dale

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization in
this handler
(such as reading config files, remote configuration to name a few). However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could you
explain where I'm making
a mistake?

Marek

No such guarantee is made. I think there is some confusion in the question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets paired
with an httpapplication instance. If the httpruntime could only respond to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[DalePres]

Application.Init will be called for each instance of the application which
approximately equals the maximum number of simultaneous requests since an
application instance handles one request at a time. Application_OnStart
will be called only once when the first instance of the application is
called.

Dale

The framework guarantees that, regardless of concurrent requests, the
application object will be initialized only once per application domain.
This happens when the first request is received. If two requests are
received at the same time, the runtime uses a spin-lock to force one request
to wait while the other is serviced guaranteeing threadsafety.

Now, once that initialization has occurred, its an open field where thread
access/concurrency is concerned so care must be taken for objects with
global scope in the application object. Good question. I had to think about
this for a while.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization
in
this handler
(such as reading config files, remote configuration to name a few).
However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could you
explain where I'm making
a mistake?

Marek

No such guarantee is made. I think there is some confusion in the
question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is
serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets
paired
with an httpapplication instance. If the httpruntime could only respond
to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the
request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[Alvin Bruney [MVP]]

Dino Esposito's book is about as good as it gets on ASP.NET. This book is
not about examples and snippets of code, it's about theory and how things
work underneath the hood.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Thank you. Where could I read more about it?

The framework guarantees that, regardless of concurrent requests, the
application object will be initialized only once per application domain.
This happens when the first request is received. If two requests are
received at the same time, the runtime uses a spin-lock to force one request
to wait while the other is serviced guaranteeing threadsafety.

Now, once that initialization has occurred, its an open field where
thread
access/concurrency is concerned so care must be taken for objects with
global scope in the application object. Good question. I had to think about
this for a while.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization
in
this handler
(such as reading config files, remote configuration to name a few).
However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could
you
explain where I'm making
a mistake?

Marek

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
No such guarantee is made. I think there is some confusion in the
question
as well.

The application_onstart event handler is an event which fires when a
request
is paired with an httpapplication instance. The guarantee is only that
this
request will be associated with this one httpapplication instance,
that
is,
sequential processing thru the http pipeline until the request is
serviced
fully by that specific httpapplication instance. Each request/instance
pair
is handled on any available thread from the threadpool. The pairing
process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets
paired
with an httpapplication instance. If the httpruntime could only
respond
to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the
request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek

 

[Scott Allen]

This locks the Application state object, which doesn't block any other
requests unless they are trying to lock the Application object also.

--
Scott
http://www.OdeToCode.com

The solution to the problem is to lock the application object early in the
code of your Application_OnStart with a call to Application.Lock(). This
will make sure that any other calls are blocked until you complete your
initialization.

Dale

Hi Alvin,

Thank you for your explanation. Still, I don't understand something.
Application_OnStart event is raised only ONCE on the first instance of
HttpApplication. Right?
I saw many examples of code where they perform some global initialization in
this handler
(such as reading config files, remote configuration to name a few). However,
I didn't see any prevention against
other HttpApplication instaces access the results of configuration BEFORE
Application_OnStart event
handler ends its execution. So I came to the question I asked. Could you
explain where I'm making
a mistake?

Marek

No such guarantee is made. I think there is some confusion in the question
as well.

The application_onstart event handler is an event which fires when a request
is paired with an httpapplication instance. The guarantee is only that this
request will be associated with this one httpapplication instance, that is,
sequential processing thru the http pipeline until the request is serviced
fully by that specific httpapplication instance. Each request/instance pair
is handled on any available thread from the threadpool. The pairing process
is not
sequential.

The responsibility of pairing falls to the httpruntime object. The
httpruntime object can handle many simultaneous concurrent
requests - limited only by the available threads in the threadpool
responsible for servicing requests. In this case, each request gets paired
with an httpapplication instance. If the httpruntime could only respond to
one request at a time, this would create a bottleneck under load. Once a
request has been received, there is an implicit guarantee that the request
can be associated with only one httpapplciation object.



--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Hi,

Is Application_OnStart event hadler guaranteed to finish its execution
before another HttpApplication object is brought into life?

Marek