Marina,

In order for a single process to use multiple instances of your
component, each from a separate memory space, you will need to have a
separate process to host each instance. You can use these instances
easily through proxy interfaces in the single client process.

The easiest way to do this is to create a COM EXE server which does
single instancing. The EXE server will contain the actual code to your
2500 classes, either by loading a DLL or by having the code directly in
the image; it is up to you.

If you do this, here is what happens on an activation request:

1. Client calls CoCreateInstance to get an instance of one of your
objects.
2. COM starts an EXE server, which registers itself for single use.
3. The requested object is created in the separate process, and an
interface is marshaled back to the first process, where it is
unmarshaled as an interface to a proxy.
4. The client uses the proxy.

Each call to CoCreateInstance will start a new process, so many
instances can peacefully coexist since they have their own memory
spaces.

Bear in mind the overhead of this approach -- namely marshaling and
extra processes. (The real physical memory overhead is not as bad as you
might think, since the EXE and DLL images for the surrogate processes
are only stored once in memory, but mapped separately to each process.)

Hope this helps!

D

-----Original Message-----
From: Marina Nudelman [mailto:marinaEIFFEL.COM]
Sent: Monday, July 23, 2001 5:13 PM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: AntiSingletons.

Hello,

We are tying to convert a big system (2500 classes) into a COM
component.
The system will continue to be used as it is now and in some cases as a
COM
DLL.
The system has been developed in the past 16 years, and major redesign
is
not an option.

Here is the problem:
The system has quite a few singletons (using static variables), which
mostly
hold configuration data and are initialized at start up.
There might be several instances running on the same machine at the same
time
with the different initialization data. As long as these are different
executables it is not a problem.
However, this is a big problem for the COM DLL.
When a client creates a COM object (via CoCreateInstance) and
initializes
it, and
then creates another object and tries to initialize it too, the
component
behavior is undefined (crash).

Obviously, when two clients access the DLL, they do not encounter the
problem because
the DLL is loaded in two different process spaces and, therefore, they
have
two distinct sets of
singletons.

My question is:
Is there any way to force this behavior with a single client?
How can I force the successive loadings of the COM DLL not to share
singletons, i.e be loaded
into different process spaces?

The COM component can only run in the main STA.

With Best regards,
Marina Nudelman
----------------------------------------------------------
Interactive Software Engineering Inc.
ISE Building, 360 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869,
Marina.Nudelmaneiffel.com
http://eiffel.com
----------------------------------------------------------

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]