需要：

在一个Windows服务执行作业从作业队列中的DB

求购：

示例code，指导或最佳实践这种类型的应用

背景：

的用户会点击一个ASHX链接，插入一行到数据库。 在我需要的窗口服务，定期轮询在这个表中的行，它应该为每一行执行工作的单位。

重点：

这不是完全新的地形对我来说。 编辑：您可以假设我知道如何创建一个Windows服务和基本的数据访问 This isn't completely new terrain for me. You can assume that I know how to create a Windows Service and basic data access.

推荐答案

既然你正在处理一个数据库队列，你必须为你已经完成工作的公平切割由于数据库的事务性质。典型的队列驱动的应用程序有一个循环的作用：

Given that you are dealing with a database queue, you have a fair cut of the job already done for you due to the transactional nature of databases. Typical queue driven application has a loop that does:

while(1) {
 Start transction;
 Dequeue item from queue;
 process item;
 save new state of item;
 commit;
}

如果处理中途崩溃，事务回滚和项目上的下一个服务处理启动。

If processing crashes midway, the transaction rolls back and the item is processed on the next service start up.

但写队列在数据库中实际上是一个很多棘手比你相信。如果部署一个幼稚的做法，你会发现，你的入队和出队是阻止对方和ashx的页面变得反应迟钝。接下来，你会发现出队主场迎战离队的死锁，你的循环不断冲击错误1205我强烈建议你阅读这篇文章的使用表作为队列。

But writing queues in a database is actually a lot trickier than you believe. If you deploy a naive approach, you'll find out that your enqueue and dequeue are blocking each other and the ashx page becomes unresponsive. Next you'll discover the dequeue vs. dequeue are deadlocking and your loop is constantly hitting error 1205. I strongly urge you to read this article Using Tables as Queues.

您的下一个挑战将是得到了集中率恰到好处。过于激进，你的数据库将热从池请求被烧毁。过于宽松和您的队列将增长高峰时间，并会流失得太慢。您应该考虑使用一种完全不同的方法：使用SQL Server内置的 队列 对象，并依靠 WAITFOR（接收） 语义。这样就可以完全民调免费自助负荷调整服务行为。实际上，有更多的：不需要启动与服务。有关详细说明，请参见异步过程执行什么我说的是：在启动处理异步SQL Server的从Web服务调用，在一个完全可靠的方式。最后，如​​果该逻辑必须在C＃过程然后就可以利用External活化剂时，它允许处理在独立的过程被托管，而不是T-SQL程序

Your next challenge is going to be getting the pooling rate 'just right'. Too aggressive and your database will be burning hot from the pooling requests. Too lax and your queue will grow at rush hours and will drain too slowly. You should consider using an entirely different approach: use a SQL Server built-in QUEUE object and rely on the magic of the WAITFOR(RECEIVE) semantics. This allows for completely poll free self load tuning service behavior. Actually, there is more: you don't need a service to start with. See Asynchronous Procedures Execution for an explanation on what I'm talking about: launching processing asynchronously in SQL Server from a web service call, in a completely reliable manner. And finally, if the logic must be in C# process then you can leverage the External Activator, which allows the processing to be hosted in standalone processes as opposed to T-SQL procedures.