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

From: Tony Proctor (tony_proctor_at_aimtechnology_NOSPAM.com)
Date: 04/06/04 

Date: Tue, 6 Apr 2004 09:21:25 +0100

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