Re: Serious problem in using COM in IIS
From: Tony Proctor (tony_proctor_at_aimtechnology_NOSPAM_.com)
Date: 07/29/04
- Next message: EMS Solutions: "Re: Increasing GDI Object Limits"
- Previous message: J French: "Re: Add a reference to an exe from activex dll?"
- In reply to: Norton: "Re: Serious problem in using COM in IIS"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 29 Jul 2004 10:25:29 +0100
Module variables (whether public or private) are a problem in IIS, i.e. when
your component is instantiated via an ASP page. If you leave any information
in them between different HTTP requests then someone else's request may
"see" that data between your requests. At the very least, this could be
security hole. However, if that data is writeable then you may also get data
corruption.
Holding a VB object in the Session variables is not recommended either as it
introduces a "thread affinity" for your ASP session. The next time you
access such as object, it has to be serviced by the original thread that
created it, and that's unlikely to be the thread you're on at the time (IIS
5.0 has a default of 25 threads in its pool). Session variables are really
designed for non-object data.
IIS is actually a multi-threaded COM+ environment. COM+ uses an "activity
threading" model. The difference between 'apartments' in this model and in
the normal COM STA's is almost the same, except to say that "activities" are
not actually bound to a fixed physical thread. This makes the architecture
much more scalable than it would be with plain COM, and allows STA objects
to make better use of thread pools.
One major difference that COM+ introduces is the concept of "activity
stacking". Under heavy load, an activity in a wait state may be suspended
while the underlying thread handles another ready-to-run activity. This
effectively means your code has to be re-entrant, and the biggest issue
there is that any Module data probably should be read-only.
Tony Proctor
"Norton" <nortonwong@hotmail.com> wrote in message
news:e80yVgUdEHA.3260@TK2MSFTNGP09.phx.gbl...
> My TestCOM has a Common Module which defines many UDT (User Defined Type)
as
> public variable
>
> and there is a INIT function in that common module to foruce clear /
> initialize the value for each variable
>
> then some class modules will perform the business operations based on the
> public variables
>
> when calling the destory function, all data will clear and set the class
> modules as nothing
>
>
> for those the class modules which will be called by ASP i will make it as
> MultiUse and not persistable
> , otherwise i will set it to private and persistable
>
> Thx for your help!
>
>
> Regards,
> Norton
>
>
>
>
>
> "Norton" <nortonwong@hotmail.com> wrote in message
> news:OVfQWeFcEHA.2620@TK2MSFTNGP09.phx.gbl...
> > Hi all
> >
> > I have problem in using a COM object in IIS
> > a COM named "ABC" was used in some ASP pages and i create an instance
for
> > ABC by using the following code
> >
> > Dim oObject
> > Set oObject= Server.CreateObject("TestCOM")
> > With oObject
> > .Init '<--a custom command to clear all variable
> > .Country= Application("CountryCode")
> > .Criteria = Request("Criteria")
> > .Process
> > .Destory '<--a custom command to clear all variable
> > End With
> > Set oObject = Nothing
> >
> > When i use the object over time, the object instance will share some
> public
> > variables defined in my ABC COM
> >
> > Here is my Project Properties for ABC Com
> > - Threading Model: Apartment Threaded
> > - Unattended Execution: True
> > - Upgrade ActiveX Controls: True
> > - Retained In Memory: True
> > - Version Compatibility: No Compatibility
> >
> > i have no idea for whats going on !!
> >
> > Any ideas on what's wrong with my code and settings?
> >
> >
> > Thx a lot!!
> > Regards,
> > norton
> >
> >
>
>
- Next message: EMS Solutions: "Re: Increasing GDI Object Limits"
- Previous message: J French: "Re: Add a reference to an exe from activex dll?"
- In reply to: Norton: "Re: Serious problem in using COM in IIS"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
