CODEWITHSUNDEEP
.netasp.netsql-servermsmqmessage-queue
Pingpong
Pingpong

Reputation: 8009

Queue Machanism in .NET and SQL Server

I have an ASP.NET web application that sends long process request to sql server. We want to change that, and instead send web request to a queue, a Windows Services pop message from the queue, and send it one by one to sql server. Currently, we need to decide what machanism is used to for the queue.

A few options to implement the queue being considered, as below:

1) A database table to simulate a queue, or

2) Windows Message queue

I want to find out the pros and cons of using windows MSMQ, and database table.

Update:

Other solution

Service Broker: suggested by Remus Rusanu

It requires deep learning curve. Perfmonece remains unknown.

Thanks

Upvotes: 2

Views: 3304

Answers (3)

Remus Rusanu
Remus Rusanu

Reputation: 294197

No need to mix MSMQ or WCF in, just use the SQL Server built-in queuing capabilities. See Asynchronous procedure execution for an example. This way you do not need a new process to dequeue MSMQ requests and process the DB long calls, you do not have to deal with separate message store and DB strore, you have one coherent back-restore for both messages and data, your messages fail over together with the data in case of High Availability situation. Not to mention that SQL Server queues scale to significantly higher margins than MSMQ (both in throughput and capacity). Using MSMQ would require you to provide a solution for all these problems: consistent backup/restore, fail over the MSMQ together with the database in case of HA incident, provide a process to read the MSMQ messages and do the DB work.

Upvotes: 4

Adam Tuliper
Adam Tuliper

Reputation: 30152

Use MSMQ implementation via WCF. Its simple - incredibly easy to setup and handles the receiver code being down as well.

Calling from Asp.Net is then trivial.

See: (and others) http://blogs.msdn.com/b/skaufman/archive/2008/02/20/processing-multiple-queues-in-fifo-order-with-wcf.aspx

Upvotes: 1

duffymo
duffymo

Reputation: 308733

A database table will require polling to check for database changes, unless you can devise some clever thing using triggers. MSMQ will not, so it wins on efficiency.

A queue can guarantee delivery, even if the consuming database is down. A database table cannot.

I'll bet that a database table is more familiar to you. MSMQ is new technology, which always carries some risk.

Setting up a queue means another moving part in your application; that can add complexity.

I think there could be a third way: a threaded queue data structure with producers/consumers. Have a look at .NET classes to see if something like that exists. Perhaps the multi-threaded capabilities in .NET can give you the asynchronous processing you need with less complexity that MSMQ.

Upvotes: 3

Related Questions