Board index » delphi » DCOM server registration on client & Threading

DCOM server registration on client & Threading

Hi all,

I'm hoping someone can tell me a better approach to registering the DCOM
server registry entries on the client without having to explicitly
install(/regserver) it once on the client and from that point on
createRemote(...) works.

Scenario:
  PublSvr.exe:
    types:
       IPubl, Publ, ISubscriberBase

  ClientFileSystemSubscriber.exe
     types:
       IFileSystemSubscriber extends(done via type library) ISubscriberBase

Client workstations installed with "ClientFileSystemSubscriber.exe" must have
"PublSvr.exe" registered for 2 two reasons:  - to enable
IFileSystemSubscriber to extend the ISubscriberBase interface  - to have a
registered GUID for the Publ CoClass

There must be a better way in which this registration and deployment can take
place.  Really all that needs to be done is to somehow include the
PublSvr.exe's type library and its registration settings.  Otherwise the
PublSvr.exe is just residing on the client machine just b/c of its type
library.

The second question is regarding threading calls back to the subscriber.  The
publisher should not be help up by any one subscribers work load.  To resolve
this I wrapped my notification within its own thread however I got an error
stating that the subscriber was marshelled to the primary thread.  My current
work around to this is to ensure that subscriber clients are threaded.  This
is allight but I would prefer the server to handle this.

Any suggest to any of the question would be greatly appreciated.
Pleases additionally copy response to ash...@usa.net
rgds ash

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

 

Re:DCOM server registration on client & Threading


Hello,

Quote

>There must be a better way in which this registration and deployment can
take
>place. Really all that needs to be done is to somehow include the
>PublSvr.exe's type library and its registration settings.  Otherwise the
>PublSvr.exe is just residing on the client machine just b/c of its type
>library.

You can have your install program merge a registry file (REG) into the
client registry and at the same time just deploy and register just the TLB
file. You will have to find out what needs to be registered for your
CoClasses and put them all into a REG file. A decent install program such as
Wise or InstallShield should be able to do this easily.

Quote
>The second question is regarding threading calls back to the subscriber.
The
>publisher should not be help up by any one subscribers work load.  To
resolve
>this I wrapped my notification within its own thread however I got an error
>stating that the subscriber was marshelled to the primary thread.  My
current
>work around to this is to ensure that subscriber clients are threaded. This
>is allight but I would prefer the server to handle this.

If you marshal correctly on the server-side to the thread that does the
callback you should not get the "marshaled for wrong thread" error. If you
just directly pass the callback pointer from thread to thread without
marshaling it, then that's when you get the error. To properly do
marshaling, use the CoMarshalInterThreadInterfaceInStream and the
CoGetInterfaceAndReleaseStream APIs.

Quote
>Any suggest to any of the question would be greatly appreciated.
>Pleases additionally copy response to ash...@usa.net
>rgds ash

--
Binh Ly
Brickhouse Data Systems, Inc.
http://www.brickhouse.com

Re:DCOM server registration on client & Threading


In article <6qthds$66...@forums.borland.com>,
  "bly" <b...@castle.net> wrote:

Binh,

Thanking you greatly for your response particurlarly for the one on
marshalling in threads.

Quote
> You can have your install program merge a registry file (REG) into the
> client registry and at the same time just deploy and register just the TLB
> file.

I'm not sure how one JUST registers a TLB file on the client.  I know only of
the regsvr32 tool but that only operates on OCX/DLL's.  What Win32 utility
are you refering to?

Quote
> marshaling it, then that's when you get the error. To properly do
> marshaling, use the CoMarshalInterThreadInterfaceInStream and the
> CoGetInterfaceAndReleaseStream APIs.

I looked at the API and got a little bit confused and wanted to confirm
whether this is the right sort of implementation:

Note, prior to the constructor below being called subsToMarsh was already
marshelled to the primary thread of the server.

constructor TNotifyThread.create( subsToMarsh: ISubscriber ) {
  __Storage := TStreamAdapter.create(TmemoryStream.create) as IStream;
  CoMarshalInterThreadInterfaceInStream( GUID_SUBS, comToMarsh,
     __Storage )
  ...
  inherited create( true );

Quote
}

destructor TNotifyThread.destroy {
  CoGetInterfaceAndReleaseStream( __Storage, GUID_SUBS,  comToMarsh );
  __Storage := nil;
  inherited destroy;

Quote
}

procedure TNotifyThread execute {
  comToMarsh.notification( 'hello world' );

Quote
}

What are the implications of this on my primary threads reference to the
ISubscriber object while the child thread is still executing.  That is is it
still marshelled in the primary thread and hence capable invoking messages
within the primary while simultaneously processing the child thread?

Once again many thanks for your suggestions on a better approach to solving
these problems.

rgds ash

Quote

> --
> Binh Ly
> Brickhouse Data Systems, Inc.
> http://www.brickhouse.com

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Other Threads