DCOM. Multiple Server Instances
Gary Butler
When I run the client on a separate machine, everything runs fine. I can
even run multiple clients programs on the same client PC with no problem.
When I start a client program on another client PC, a second instance of the
ActiveX server is started. When I start a third client program on a third
PC, a third instance of the ActiveX server is created.
I have the server's class set to MultiUse with a thread per object model.
I need to share objects in the server with the client programs.
Gary Butler
Jim Covington
"Interactive User." Any other ideas?
Jim
Dean R. Olynyk wrote in message <90364674...@neptune.uniserve.com>...
>If you load DCOMCNFG, is the Identity set to "Launching User"? If it is,
the
>below will result. Change it to interactive or "This.." and things will
run
>as you had hoped.
>
>
>d.
>_______________________________________________
>Dean Olynyk
>InterLogic Engineering Ltd.
>mailto://dolyn...@GGGiel.com (lose the gees)
>http://www.iel.com
Jim Covington
Thanks for answering. Here's some more info:
Server is a PII 400, 96MB
All Clients & server running NT 4.0, SP3
All clients & server in same domain
Cleints & server logged on as different users.
Project made in VB5, SP3
Server is not set for unattended execution. (It has a log window visible at
runtime.)
Server class is set as multiuse
Server uses Thread pooling with 1 thread
Start mode is "ActiveX Component"
The server has "Form1.Show" in the Initialize event.
The client does not have an early-bound reference to the server because the
server has an early-bound reference to the client.
General operation - the client starts (or hopefully connects to) the server
and passes the server a reference to itself. This allows multiple clients in
the domain to share information through the same server without connecting
directly to each other.
Multiple clients from the same PC will connect to the same server. A new
client (different NT user) from another PC will instantiate and connect to a
different server. The intent is to have all clients connect to the same
instance of the server.
Client side code:
If Server Is Nothing Then Set Server =
CreateObject(SERVER_CLASS_NAME)
SERVER_CLASS_NAME is, you guessed it, a constant set to the server class
name (IE_Object_MBX_Server.CIE_OBJ_MBX_Server)
Interesting tidbit: If the client is on the same PC as the server, then
Form1 appears and the server shows up in the applications list as well as
the process list.
If the client is on a different PC (logged on as a different NT user), Form1
does not appear and the server does not show up in the applications list -
only the process list.
I have not yet tried logging on as the same NT user from a different PC -
I'll get to that later today.
Jim
Dean R. Olynyk wrote in message <90365402...@neptune.uniserve.com>...
>Perhaps. Could I get more information?
>
>OSes involved. Number of domains involved. Instancing on server. Snippet
of
>client side code. Eye of newt.
>
Jim Covington
The clients are ActiveX DLL's. They are set to run as the "Interactive
User." Permissions are set wide open. We want to avoid creating a new user
becasue one of the goals of this product is to have low installation &
configuration overhead.
I tried logging on to the remote machine (client) using the same userID as
the local machine (server.) I got the same behavior.
Mark Alsop (thanks, Mark!) came up with an idea. I'm not sure that that's
exactly it, though. We have been able to connect multiple clients to a
single server before - I'm just not sure how we did it. The answer to the
question "What did you change between now and then?" is "Everything!" We're
using different PC's but we thought we got all of the settings and
configurations tranferred. There's some setting somewhere that we're
missing.
Mark found this in the "Specifics" section of the help for App.PrevInstance:
------
A computer running Windows NT can support multiple desktops. When you're
using a component designed to work with distributed COM, this can result in
the following scenario:
· A client program in a user desktop requests one of the objects the
component provides. Because the component is physically located on the same
machine, the component is started in the user desktop.
· Subsequently, a client program on another computer uses distributed COM to
request one of the objects the component provides. A second instance of the
component is started, in a system desktop.
There are now two instances of the component running on the same NT
computer, in different desktops.
This scenario is not a problem, unless the author of the component has
placed a test for App.PrevInstance in the startup code for the component, to
prevent multiple copies of the component from running on the same computer.
In this case, the remote object creation will fail.
-------
Dean R. Olynyk wrote in message <90371910...@neptune.uniserve.com>...
>Hi Jim,
>
>So are the clients of this server ActiveX exe's? Are their locations
static?
>
>In any case, have you tried creating a new user on that server, and
>configuring the Server using DCOMCNFG to run the process as the newly
created
>user?
>
>I believe you said it was set up for Interactive User... right?
F.F.MAK
Try to search the Coffee example in MSDN. I can't remember what number the
article is but it may help.
Eddy
Jim Covington
I checked it out. Thanks for the reference.
I'm trying to do exactly what they do in the coffee monitor project.
Unfortunately, the coffee project doesn't get into DCOM. I see the correct
behavior when I connect from the same machine just using COM - even though
every client creates a new instance of the class, all instances are provided
by one server. Each class gets the information it needs from variables in a
module of the server.
The problem is that additonal clients coming in from different machines
create a new server to provide instances of the class. The coffee project
doesn't cover this.
Thanks for the reference!
Jim
F.F.MAK wrote in message <01bdcdac$1c299c80$ee31...@ip238.epro.com.hk>...
Christopher
Rather than each project using New or CreateObject to get a new copy of the
server, they just call the "Connect" method of the class factory, which
returns a the single server object running in it's address space.
To accomplsih this, just create a CFactory class with GlobalMultiUse
Instancing, and put this code in it.
Option Explicit
Public Function Connect() As Server
If gServer Is Nothing Then Set gServer = New Server
Set Connect = gServer
End Function
And declare a standard module with 'Public gServer as Server' in it. The
from you client app, just add:
Dim mServer as Server
Set mServer = Connect
And there you go! You client now has a reference to the same server that
every other client has a reference to!
Hope this helps!
-Christopher G.
Jim Covington <jcov...@SPAM.inteng.com> wrote in article
<OLttL73...@uppssnewspub04.moswest.msn.net>...
Jim Covington
If the class factory object is local to the client's machine, then how does
the class factory <not> create a new instance of the server, just as the
client does?
If the class factory is local to the server machine, then how does the
client get a reference to the class factory?
Still pondering ideas...I'm trying running it as a service now. It worked
once (remote clients connected to the service), then stopped working (remote
clients made a new copy of the server)...<sigh>
Christopher wrote in message <01bdcf7f$bccbc8f0$aa4783a7@nt7951a>...
Christopher
project. You don't have to worry about getting a reference to the
ClassFactory. As long as you include the server object in the referencs of
your client project, DCOM will handle the rest. And since any CFactory
objects that may be created all return the same instance of your server
object, if doesn't matter that each client uses a new CFactory object.
Jim Covington <jcov...@SPAM.inteng.com> wrote in article
<eT80ijD...@uppssnewspub04.moswest.msn.net>...
> I see a similar problem using the class factory...
>
Jim Covington
for the task I'm trying to accomplish.)
That means the client can't early bind to the server. If I do, I create a
circular reference and I get the "function or interface marked as
restricted" error when I compile.
You're right that it doesn't matter if each client points to a different
CFactory. The problem is that when clients from different machines create
server objects, they each launch their own copy of the EXE (even though it's
set to Multiuse.) Therefore the CFactories will be pointing to multiple
copies of the server, not one.
Christopher wrote in message <01bdd047$3f7b9100$aa4783a7@nt7951a>...