views:

90

answers:

2

I am currently building two windows services:

  • The first takes messages from an internet connection and inserts these into a database. This is designed to be fast and stable and not do any other processing

  • The second performs a batch process with any new messages that have arrived since it last ran.

I am trying to think of a way so that the second service will only run its batch process when new messages are ready to be processed and if the second service errors the first service will keep going and vice versa. At the moment it uses a loop every 5 seconds.

I am currently thinking of using a message queue, where the first service writes a message only if the queue is empty, and the second service will see if the queue contains any messages, if not go into an asynchronous wait until a message arrives and then remove the message and run. Therefore using the queue not really as a queue but as a binary switch that when it's state changes causes an event to be triggered to the second service.

I presume there is a better way to do this that I have not encountered could someone please point me in the right direction?

+2  A: 

Actually, your way is EXACTLY how I would implement this for these results. With MSMQ, you don't have to check to see if you have a message written to the queue, the first service just writes to the queue, and the second service just reads from it to process it (when it is active).

The beauty of using MSMQ is that one or the other service can be down, but the queues will be up, so you can continue processing.

casperOne
Thanks for your answer casperOne. I have elaborated on my question slightly above. I may actually be abusing the queue mechanism here, as I want to store the messages in the database and not them all to the queue, so would be using the queue as a binary switch that triggers events. Is this ok?
bobwah
You could do something like that. When you send a message in the queue, you simply send the id which corresponds to the id of the record(s) in the database. However, on both sides, you should wrap the writing of the database record and the queue message, as well as the reception in a transaction.
casperOne
+1  A: 

Looks to me as if for this case all you need is a mailslot. The first service stores into the DB and then sends a "work to do" message. The other one just awaits inbound messages.

MSMQ is a bit heavyweight for something this simple. Then again you could just use MSMQ and get rid of that DB entirely too. That would be the way to do it.

Bob
I agree, though some of the people above me do not. The argument they have is that if the queue became corrupt or out of memory we could lose messages. You can argue the database could have the same problems though this is what they decided.
bobwah