Since my last two attempts don’t seem to be generating any responses, I’ll
simplify the question :
When the IIS thread pool is accessing a COM DLL, what must I do to insure
that each IIS thread has a one-to-one relationship with instances of the COM
objects?
Example: Presume five users simultaneously visit the IIS-powered website,
all of whom do something which accesses the COM DLL. Five threads from the
IIS thread pool fire up, each taking responsibility for one of the users.
Five COM objects should be instantiated, one associated with each thread. As
the threads write property values into the objects, we must make certain
that the threads access only only one object, and that object must be the
same object every time so that the threads don’t overwrite each other’s
values. Since the threads outlive the user’s request and response, I presume
all five objects will continue to exist too… and thus we must maintian the
1:1 relationship between instantiated objects and the IIS worker threads
basically forever.
I can’t find anything in MSDN which directly addresses this topic.
Assistance is appreciated!
Thanks!
> Example: Presume five users simultaneously visit the IIS-powered website,
all of whom do something which accesses the COM DLL. Five threads from
If you want to maintain 1:1 relationship between IIS’s clients and your
instances - using ASP’s Session object and Session_OnStart event is the very
best idea.
Otherwise, you will need to do all this cookies stuff by hand.
Max
At 04:25 AM 06/23/2000 +0400, you wrote:
> Example: Presume five users simultaneously visit the IIS-powered website,
> all of whom do something which accesses the COM DLL. Five threads fromIf you want to maintain 1:1 relationship between IIS’s clients and your
instances - using ASP’s Session object and Session_OnStart event is the very
best idea.
Otherwise, you will need to do all this cookies stuff by hand.
No, I specifically do NOT want to link objects to sessions, nor does this
involve cookies. I need to relate objects to threads. Each of IIS’s
threads needs the ability to create and use an object, but we must prevent
threads from using any but their own single object. This has nothing to do
with users, but only with the thread pool that IIS maintains.
> No, I specifically do NOT want to link objects to sessions, nor does this
involve cookies. I need to relate objects to threads. Each of IIS’s
threads needs the ability to create and use an object, but we must prevent
threads from using any but their own single object. This has nothing to do
Then “Apartment” threading model is exactly what you need.
Max