Emlyn (pentacle) wrote:
> Thanks thanks thanks thanks thanks!
>
> My problem is that I'm trying to make a call from a client to a server,
> where the server is not trusted to actually process the call in a reliable
> way; in particular, where the call may never return. So, I want to make an
> asynchronous call - then the server can balls up, but the client can
> continue.
> I hacked together a pretend asynchronous call between com objects, using
an
> intermediate out-of-process object. The client calls the intermediate
> object, and the intermediate object sets a timer (1 msec) and returns the
> call (so the client can get on with it's life). Meanwhile, the timer goes
> off in the intermediate object, which then calls the server as the client
> has requested. If the server hangs, then the intermediate object does too,
> but the client is clear of the damage.
> Gross, isn't it? I think these message queues might be a better
solution...
Definitely. You put an outgoing queue on the client, and an incoming queue
on the server, and set up MSMQ to route messages from one to the other. You
have a server-side object instantiate an MSMQQueue object, and then put code
in the 'message received' event handler that reads incoming messages and
calls COM objects as appropriate. If the network goes down your messages
just stack up in the outgoing queue, and they get delivered when it comes
back up. If the server component dies MTS will kill it for you and
instantiate a new copy for the next method call. You can even have MSMQ keep
the queues on disk, to ensure that power failures don't make the app loose
messages.
That's all the NT way of doing it. In Win2K you can just designate a COM
object as asynchronous when you install it in MTS, and then COM+ takes care
of managing all the plumbing for you.
Billy Brown
bbrown@transcient.com
http://www.transcient.com
This archive was generated by hypermail 2b29 : Thu Jul 27 2000 - 14:10:31 MDT