Using DCOM to broadcast messages

[Mike Carter]

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

[Steve Gerrard]

"Mike Carter" <mi********@pos tmaster.co.uk> wrote in message
news:95******** *************** ***@posting.goo gle.com...

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

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.

[Mike Carter]

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" <no************ *@comcast.net> wrote in message news:<cY******* *************@c omcast.com>...

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. "Mike Carter" <mi********@pos tmaster.co.uk> wrote in message
news:95******** *************** ***@posting.goo gle.com...

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