Using DCOM to broadcast messages

Re: Using DCOM to broadcast messages


"Mike Carter" <mikecarter@pos tmaster.co.uk> wrote in message
news:952a30c9.0 404070809.78541 [email protected] gle.com...[color=blue]
> DCOM people,
>
> I used to use TIBCO Rendezvous software to do the following, but I
> can't anymore, so I have implemented my solution using DCOM.
>
> I have a DCOM server component that receives events from an external
> data provider, writes this data to a SQL Server database and raises a
> new data event.
>
> This event is then received by several "listening" client components.
> Depending on each client's preferences, this may or may not lead to
> the querying of the database for the new information.
>
> Sometimes (I'm guessing when a lot of data comes in from the external
> source) there can be a delay as messages appear to be queueing up at
> the server component. From what I understand of DCOM, processing
> cannot continue on the server component until all the clients have
> processed the event that was raised.
>
> I would rather make the events asynchronous, and I understand you can
> do that using threads but that sounds too difficult. Is there a
> simple way to keep the clients up to date with new data developments,
> without them being "connected" to the server component?
>
> Hope someone can help me here.
>
> Many thanks,
>
> - Mike Carter[/color]

Just some ideas here, nothing for sure:
1. Client could poll on a timer. On the timer event, it could create a
server object, check whether there is an update (maybe a LatestUpdate
property as DateTime), then release the server object before running a
data query.
2. Client could process the data event quickly, by not running a query
in the event handler. Instead, it could set a local timer and exit the
event handler. Then it can run the query on the local timer event.
3. If you don't want to modify the client side, you could have a proxy
object on the server, one per client, which connects to the main server
object, and implements 1 or 2 above. Instead of running the query, it
would raise its own event back to the client.

Re: Using DCOM to broadcast messages

Thanks for your suggestions Steve, I think 2 might help me out, there
is currently a lot of processing on the event procedure that could be
causing the slow-down. Also, with a timer-based solution, each client
would be querying the database at slightly different times which can't
hurt either.

"Steve Gerrard" <notstevegerrar [email protected]> wrote in message news:<cYWdnZjwh [email protected]> ...
[color=blue]
>
> Just some ideas here, nothing for sure:
> 1. Client could poll on a timer. On the timer event, it could create a
> server object, check whether there is an update (maybe a LatestUpdate
> property as DateTime), then release the server object before running a
> data query.
> 2. Client could process the data event quickly, by not running a query
> in the event handler. Instead, it could set a local timer and exit the
> event handler. Then it can run the query on the local timer event.
> 3. If you don't want to modify the client side, you could have a proxy
> object on the server, one per client, which connects to the main server
> object, and implements 1 or 2 above. Instead of running the query, it
> would raise its own event back to the client.[/color]
[color=blue]
> "Mike Carter" <mikecarter@pos tmaster.co.uk> wrote in message
> news:952a30c9.0 404070809.78541 [email protected] gle.com...[color=green]
> > DCOM people,
> >
> > I used to use TIBCO Rendezvous software to do the following, but I
> > can't anymore, so I have implemented my solution using DCOM.
> >
> > I have a DCOM server component that receives events from an external
> > data provider, writes this data to a SQL Server database and raises a
> > new data event.
> >
> > This event is then received by several "listening" client components.
> > Depending on each client's preferences, this may or may not lead to
> > the querying of the database for the new information.
> >
> > Sometimes (I'm guessing when a lot of data comes in from the external
> > source) there can be a delay as messages appear to be queueing up at
> > the server component. From what I understand of DCOM, processing
> > cannot continue on the server component until all the clients have
> > processed the event that was raised.
> >
> > I would rather make the events asynchronous, and I understand you can
> > do that using threads but that sounds too difficult. Is there a
> > simple way to keep the clients up to date with new data developments,
> > without them being "connected" to the server component?
> >
> > Hope someone can help me here.
> >
> > Many thanks,
> >
> > - Mike Carter[/color][/color]