Ed Sinek
Ed Sinek

Reputation: 4977

to MSMQ or not to MSMQ? (or SQL Table as the Queue)

I've got a distributed system where there will be 1 SQL Server, 1-n processing servers, and 1-n data suppliers (hardware devices across the network). The data being supplied will require processing prior to going into the relational DB structure - performed by the processing servers (as windows services - .net code to parse the data, process it, and insert it into the relational structure.)
To handle the potential load and not slow down the data suppliers, I want to implement a queue, but I'm not sure I want to add the complexity of an MSMQ server to the mix. Is there a good alternative to MSMQ, such as using the DB (a flat table) as the queue? Does .NET provide any out-of-the-box support for DB queues, or is there another option for reliable queueing?
Thanks

Upvotes: 12

Views: 3060

Answers (2)

StingyJack
StingyJack

Reputation: 19459

Out of the two options, MSMQ is actually the more simplistic. If you need the ability to re-prioritize work, or have processing agents only pick certain types of queued jobs, then you cannot use MSMQ. If you do not need any of those bells and whistles, then MSMQ is cake to use with .NET.

Upvotes: 2

fARcRY
fARcRY

Reputation: 2358

I would use MSMQ, it doesnt add that much complexity, and it is so easy to backup the messages, so processing can continue even after a system restart. You could use something like SSB.

Upvotes: 4

Related Questions