By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,536 Members | 1,504 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,536 IT Pros & Developers. It's quick & easy.

Application_OnStart event

P: n/a
Hi,

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

Marek
Nov 18 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:wv**************@newssvr32.news.prodigy.com.. .
Hi,

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

Marek



Nov 18 '05 #2

P: n/a
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
news:eb**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:wv**************@newssvr32.news.prodigy.com.. .
Hi,

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

Marek


Nov 18 '05 #3

P: n/a
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:V3***************@newssvr32.news.prodigy.com. ..
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
news:eb**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:wv**************@newssvr32.news.prodigy.com.. .
> Hi,
>
> Is Application_OnStart event hadler guaranteed to finish its execution
> before another HttpApplication object is brought into life?
>
> Marek
>
>



Nov 18 '05 #4

P: n/a
Thank you. Where could I read more about it?

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:us**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:V3***************@newssvr32.news.prodigy.com. ..
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
news:eb**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:wv**************@newssvr32.news.prodigy.com.. .
> Hi,
>
> Is Application_OnStart event hadler guaranteed to finish its execution > before another HttpApplication object is brought into life?
>
> Marek
>
>



Nov 18 '05 #5

P: n/a
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

"Marek" <ma**************@sbcglobal.net> wrote in message
news:V3***************@newssvr32.news.prodigy.com. ..
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
news:eb**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:wv**************@newssvr32.news.prodigy.com.. .
Hi,

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

Marek



Nov 18 '05 #6

P: n/a
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

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:us**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:V3***************@newssvr32.news.prodigy.com. ..
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
news:eb**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:wv**************@newssvr32.news.prodigy.com.. .
> Hi,
>
> Is Application_OnStart event hadler guaranteed to finish its execution > before another HttpApplication object is brought into life?
>
> Marek
>
>



Nov 18 '05 #7

P: n/a
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:xD***************@newssvr16.news.prodigy.com. ..
Thank you. Where could I read more about it?

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:us**************@TK2MSFTNGP09.phx.gbl...
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
"Marek" <ma**************@sbcglobal.net> wrote in message
news:V3***************@newssvr32.news.prodigy.com. ..
> 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
> news:eb**************@TK2MSFTNGP09.phx.gbl...
>> 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
>> "Marek" <ma**************@sbcglobal.net> wrote in message
>> news:wv**************@newssvr32.news.prodigy.com.. .
>> > Hi,
>> >
>> > Is Application_OnStart event hadler guaranteed to finish its execution >> > before another HttpApplication object is brought into life?
>> >
>> > Marek
>> >
>> >
>>
>>
>>
>>
>
>



Nov 18 '05 #8

P: n/a
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

On Sun, 9 May 2004 20:51:03 -0500, "DalePres" <no****@nomail.com>
wrote:
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

"Marek" <ma**************@sbcglobal.net> wrote in message
news:V3***************@newssvr32.news.prodigy.com ...
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
news:eb**************@TK2MSFTNGP09.phx.gbl...
> No such guarantee is made. I think there is some confusion in thequestion > 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 isserviced > 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 getspaired > with an httpapplication instance. If the httpruntime could only respondto > one request at a time, this would create a bottleneck under load. Once a
> request has been received, there is an implicit guarantee that therequest > 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
> "Marek" <ma**************@sbcglobal.net> wrote in message
> news:wv**************@newssvr32.news.prodigy.com.. .
> > Hi,
> >
> > Is Application_OnStart event hadler guaranteed to finish its execution
> > before another HttpApplication object is brought into life?
> >
> > Marek
> >
> >
>
>
>
>



Nov 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.