Poll database every second and start n long running tasks
A legacy app is writing to our database potentially every second. It can write multiple entries in one go. Each of these entries needs to be worked on asap and requires calling a long running external web service for each of these entries.
I am wondering about the best architecture / pattern to handle this: We need to poll the database every second and then - depending on the number of new entries - start n of these long running tasks (the external web service being called). These tasks will write their result back to the database where it is picked up by the legacy app.
Should I "simply" use a combination of System.Threading.Tasks and System.Timers.Timer to implement this or are there better alternatives? (based on .Net 4.0 & SQL Server 2008)
UPDATE: We don't have SQL Server Service Broker enabled and ideally I would like to go for a solution without it; at least I am thinking it's a bit of an overhead for this task. But I am happy to be convinced otherwise.
To me more specific about the implementation:
I would use a windows server to query the database every second (as stated in your requirements).
Then I would be make asynchronous WCF as these can be long running as you said.
HTH.
This question raises more concerns about global design than specifics .net feature. I would definitely go with a trigger solution on record modifications. To avoid DB loads, this trigger will only write the nature of the event : id of the record, event type in a separate event table. A polling process will read only the events table, and process events as appropriate and archive them for statistics purposes. By this way you have controls over load pick, you can tune your long running process to fit your performance requirements and you have traces of what have been done. I have built a similar system with about 100 millions of events arriving at once without any problem.
链接地址: http://www.djcxy.com/p/74512.html