468,321 Members | 1,895 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,321 developers. It's quick & easy.

Multiple application objects?

SL
All,

As I understand it, a single application (i.e. IIS virtual directory)
in ASP.NET may in fact have more than one corresponding
HttpApplicationState object (more or less one per server thread, I
think). During each request, only one of these objects is exposed to
the page as Page.Application. This seems to be supported by the fact
that when I use the debugger, I can see the Application_Start event
firing more than one time even though IIS has not been shut down in
between.

My question is this - within my application, I want to instantiate a
specific COM object, and then I want to store this one instance some
place where it will a) remain until IIS shuts down and b) is
accessible by all pages, during all requests, regardless of exactly
which application object is being used by each request. Due to the
way that this particular COM component was written, I can only have
one instance of the COM object in question at any time. If I try to
have more than one instance exist concurently, they both enter an
invalid state and can no longer be used.

What I initially tried was instantiating my object on
Application_Start, and then saving myObject to the application object.
But later on, Application_Start invariably fires again and I end up
re-creating the object, because I can not see it on the current
application object. Meanwhile the original application object still
has its own instance of my COM object, so two instances now exist but
they both enter an invalid state.

Any help would be greatly appreciated.
Nov 18 '05 #1
3 1701
I'm afraid you're mistaken in your initial premise. There is only one
Application. Check Task Manager if you don't believe me. I have no idea what
you're doing to see the Application_Start event firing more than once, but
it only fires one time when the application starts. When you debug, it will
restart and fire every time you re-run the debugger.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"SL" <sk***********@yahoo.com> wrote in message
news:53**************************@posting.google.c om...
All,

As I understand it, a single application (i.e. IIS virtual directory)
in ASP.NET may in fact have more than one corresponding
HttpApplicationState object (more or less one per server thread, I
think). During each request, only one of these objects is exposed to
the page as Page.Application. This seems to be supported by the fact
that when I use the debugger, I can see the Application_Start event
firing more than one time even though IIS has not been shut down in
between.

My question is this - within my application, I want to instantiate a
specific COM object, and then I want to store this one instance some
place where it will a) remain until IIS shuts down and b) is
accessible by all pages, during all requests, regardless of exactly
which application object is being used by each request. Due to the
way that this particular COM component was written, I can only have
one instance of the COM object in question at any time. If I try to
have more than one instance exist concurently, they both enter an
invalid state and can no longer be used.

What I initially tried was instantiating my object on
Application_Start, and then saving myObject to the application object.
But later on, Application_Start invariably fires again and I end up
re-creating the object, because I can not see it on the current
application object. Meanwhile the original application object still
has its own instance of my COM object, so two instances now exist but
they both enter an invalid state.

Any help would be greatly appreciated.

Nov 18 '05 #2
while there are multiple Application instantences, there is only one cache,
and Application start only fires once per AppDomain.

here is the rub. asp.net will load a new appdomain for your site if it
believes there are any code changes, or that the site needs recycling, or
its hit the timeout. the old appdomain will stay in memory until its
serviced all of its current transactions, and run its shutdown.

while appdomains have their own memory and .net objects are distinct, com
objects use the asp.net memory. you will have to write some unmanaged code
to manage the com objects. the unmanged code will be called by application
start, and return the handle to the com object. it internally will need to
create one instance of the com object and track that its been created.

you also may be able to host the com object in com+ and make it a singleton.

-- bruce (sqlwork.com)
"SL" <sk***********@yahoo.com> wrote in message
news:53**************************@posting.google.c om...
All,

As I understand it, a single application (i.e. IIS virtual directory)
in ASP.NET may in fact have more than one corresponding
HttpApplicationState object (more or less one per server thread, I
think). During each request, only one of these objects is exposed to
the page as Page.Application. This seems to be supported by the fact
that when I use the debugger, I can see the Application_Start event
firing more than one time even though IIS has not been shut down in
between.

My question is this - within my application, I want to instantiate a
specific COM object, and then I want to store this one instance some
place where it will a) remain until IIS shuts down and b) is
accessible by all pages, during all requests, regardless of exactly
which application object is being used by each request. Due to the
way that this particular COM component was written, I can only have
one instance of the COM object in question at any time. If I try to
have more than one instance exist concurently, they both enter an
invalid state and can no longer be used.

What I initially tried was instantiating my object on
Application_Start, and then saving myObject to the application object.
But later on, Application_Start invariably fires again and I end up
re-creating the object, because I can not see it on the current
application object. Meanwhile the original application object still
has its own instance of my COM object, so two instances now exist but
they both enter an invalid state.

Any help would be greatly appreciated.

Nov 18 '05 #3
Bruce,

Thanks very much for the reply.

I had thought I had seen a post indicating that there is more than one
application object, which I thought explained the behavior I've been
seeing.

I've mostly been using the application with the VS.NET debugger, which
combined with the fact that this COM object only allows one instance at
a time, has been causing me all sorts of problems. In any case your
explanation of when the application starts and stops in relation to the
debugger is a big help.

Do you know if, when the server restarts the application due to the
debugger or a detected code change, the Application_End event reliably
fires? In my initial attempt to make this all work, I creted the
object in application_Start and properly disposed of it in the
application_end event, but at least in debugging I still had problems
from multiple instances of the COM object.

I don't have the source code to the COM object in question and I won't
be able to get it, so modifying it at that level is not in the cards.
In fact, I've spoken to the developer of the COM object, and it was
written in VB6 as an ActiveX EXE but was not written as a singleton.

Thanks in advance for any help.
bruce barker wrote:
while there are multiple Application instantences, there is only one cache, and Application start only fires once per AppDomain.

here is the rub. asp.net will load a new appdomain for your site if it believes there are any code changes, or that the site needs recycling, or its hit the timeout. the old appdomain will stay in memory until its
serviced all of its current transactions, and run its shutdown.

while appdomains have their own memory and .net objects are distinct, com objects use the asp.net memory. you will have to write some unmanaged code to manage the com objects. the unmanged code will be called by application start, and return the handle to the com object. it internally will need to create one instance of the com object and track that its been created.
you also may be able to host the com object in com+ and make it a singleton.
-- bruce (sqlwork.com)
"SL" <sk***********@yahoo.com> wrote in message
news:53**************************@posting.google.c om...
All,

As I understand it, a single application (i.e. IIS virtual directory) in ASP.NET may in fact have more than one corresponding
HttpApplicationState object (more or less one per server thread, I
think). During each request, only one of these objects is exposed to the page as Page.Application. This seems to be supported by the fact that when I use the debugger, I can see the Application_Start event
firing more than one time even though IIS has not been shut down in
between.

My question is this - within my application, I want to instantiate a specific COM object, and then I want to store this one instance some place where it will a) remain until IIS shuts down and b) is
accessible by all pages, during all requests, regardless of exactly
which application object is being used by each request. Due to the
way that this particular COM component was written, I can only have
one instance of the COM object in question at any time. If I try to have more than one instance exist concurently, they both enter an
invalid state and can no longer be used.

What I initially tried was instantiating my object on
Application_Start, and then saving myObject to the application object. But later on, Application_Start invariably fires again and I end up re-creating the object, because I can not see it on the current
application object. Meanwhile the original application object still has its own instance of my COM object, so two instances now exist but they both enter an invalid state.

Any help would be greatly appreciated.


Nov 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by TT (Tom Tempelaere) | last post: by
7 posts views Thread by jsale | last post: by
2 posts views Thread by Tumurbaatar S. | last post: by
9 posts views Thread by Graham | last post: by
reply views Thread by Sebastian Loncar | last post: by
3 posts views Thread by breeto | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by howard w | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.