Re: Multiple instances of app under IIs and global com object - is it a problem?

From: Rogue Petunia (roguepetunia_at_NOSPAMnyc.rr.com)
Date: 04/09/04 

Date: Fri, 9 Apr 2004 17:27:20 -0400

OK, Tony, so I called it a "theory". You said tomato I say tomato ;)
thanks for your follow up. It was more detailed than the explanation I got
from the boss and makes it even more clear.
this threading business is a lot to get one's head around - especially, as
you say, because it doesn't work that way in the IDE, so you can develop
without even realizing the implications until QA.

-Rogue Petunia

"Tony Proctor" <tony_proctor@aimtechnology_NOSPAM.com> wrote in message
news:OZvrK$6GEHA.3904@TK2MSFTNGP12.phx.gbl...
> It's not really a "theory" Rogue. This is how VB works in a threaded
> environment. Some of our core products are totally reliant on this
behaviour
> (i.e. they've been designed around the way the system works)
>
> If IIS has, say, a pool of 25 threads, and your ASP Sessions do not
exhibit
> "thread affinity" (which is a very common design flaw), then it should be
> effectively random which of those 25 threads services each of your browser
> requests. Hence, if you store anything in Module-level data (values or
> objects) then you may not be looking at the same data when your next
request
> is serviced.
>
> This is why Session-level variables were provided -- in the Session
> collection. However, beware that storing objects in Session variables
> introduces a "thread affinity" (i.e. your ASP session is then bound to
that
> thread, whether other threads are free to use or not), and will introduce
> serious scalability issues. Also, session variables are useless in a "web
> farm" scenario as they're specific to each web server.
>
> In effect, this multiplicity of Module-level data means (a) that you
cannot
> store a writable value (e.g. a counter) and guarantee to see it on your
next
> request, and (b) that your request may well see data left by a different
> session, and so introduce either a program bug or a security hole. In
> reality, Module-level data is only useful in an IIS context for fixed
data,
> or caches, but not for preserving session state.
>
> Finally, you'll notice that none of this is reproducible when testing your
> component via the IDE. This is because the IDE forces a single-threaded
> environment, and so there is then only one copy of your data. This makes
> testing a real PIA.
>
> Tony Proctor
>
> "Rogue Petunia" <roguepetunia@NOSPAMnyc.rr.com> wrote in message
> news:ukfa9B1GEHA.2876@TK2MSFTNGP09.phx.gbl...
> > just a follow up on this old post.
> >
> > A number of people postulated the same theory as Tony. But, it has
borne
> > out that declaring a global variable in a .bas module is problematic
when
> > running an app that will have multiple instances under IIS. This did
> cause
> > a problem for us. We were experiencing error messages that seemed quite
> > unrelated to the current page. Turns out a global variable in a .bas
file
> > was not clean - when a new request came in for a page, the global
variable
> > still had the old value.
> >
> > Here's how it was explained to me:
> > Scope of variables declared in a module or .bas file is global and
> > independant of objects instantiated explicitly within the lifetime of
the
> > running ASP page. Based on normal IIS configurations of caching
> applications
> > (.dll's), the scope of this memory will be shared between subsequent IIS
> > requests. A simple illustration of this is that one can implement a
> counter
> > using a variable defined by a module file to record the persistance
> behavior
> > of that memory during subsequent IIS requests.
> >
> > Based on this, if declaring a simple variable in this way would be
> > problematic, then it seems that declaring an object would have similiar
> > troubles.
> >
> > Thanks,
> > Rogue
> >
> > "Tony Proctor" <tony_proctor@aimtechnology_NOSPAM.com> wrote in message
> > news:ezS01spDEHA.3236@TK2MSFTNGP09.phx.gbl...
> > > OK Rogue, I think I understand what you're asking. I assume your
'myApp'
> > is
> > > a VB DLL hosted in IIS via some ASP page.
> > >
> > > IIS is a multi-threaded environment. By default (in IIS V5.0) there's
a
> > pool
> > > of 25 threads, and these are used to service requests from your web
> > clients.
> > > If you have a read of this recent thread:
> > >
> > >
> > >
> >
>
http://www.google.ie/groups?safe=images&ie=UTF-8&oe=UTF-8&as_ugroup=*.vb&as_usubject=Using%20a%20non-thread-safe%20dll%20in%20a%20com%20object&lr=&hl=en
> > >
> > > you'll see that your component shares no global data between those
> > threads.
> > > In other words, they each operate pretty much independently, and each
> > would
> > > have separate instances of your logging object.
> > >
> > > One area that will affect you though is file access. If any of your
> > threads
> > > were to open your logging file using normal VB I/O then the resulting
> > > exclusive lock would prevent other threads from accessing it. The
> > following
> > > post might help you in resolving that.
> > >
> > >
> >
>
http://www.google.ie/groups?safe=images&ie=UTF-8&oe=UTF-8&as_umsgid=OON2xf59DHA.2644@TK2MSFTNGP11.phx.gbl&lr=&hl=en
> > >
> > > Tony Proctor
> > >
> > > "Rogue Petunia" <roguepetunia@NOSPAMnyc.rr.com> wrote in message
> > > news:efNzlNeDEHA.3784@TK2MSFTNGP10.phx.gbl...
> > > > Hello,
> > > > I have created a dll for handling requests to write to log files and
> the
> > > > event viewer. Let's call it Logger.dll.
> > > > I have a vb application that will running under IIs, let's call it
> > myApp.
> > > > There will be multiple instances of myApp.
> > > >
> > > > myApp has many classes as well as code modules. In each procedure
of
> > > myApp,
> > > > error handling code needs to use an object from the Logger.dll.
> > > >
> > > > My thinking was to instantiate a global object in myApp so the
object
> > > would
> > > > be available throughout the application. To do this, I declared the
> > > object
> > > > in a code module of myApp. Let's call the code module,
myDefinitions.
> > > It
> > > > has been pointed out that this could be a problem because the
multiple
> > > > instances of myApp running on the server will point to the one
common
> > > > module, myDefinitions, where the object was declared. If one
instance
> > of
> > > > myApp sets the object to nothing, then another instance needs to
> access
> > > the
> > > > object, it's gone. and kablewly.
> > > >
> > > > Question:
> > > > myApp will be running multiple instances under IIs. Will IIs
created
> > > > multiple instances of the code module, myDefinitions, with each
> instance
> > > of
> > > > myApp? Or will there be only one, to which the multiple instances
of
> > > myApp
> > > > will point?
> > > >
> > > > How can I test this?
> > > >
> > > > Thanks!
> > > >
> > > > Rogue Petunia
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages