Question

Scenario: A WCF service receives an XDocument from clients, processes it and inserts a row in an MS SQL Table.

Multiple clients could be calling the WCF service simultaneously. The call usually doesn't take long (a few secs).

Now I need something to poll the SQL Table and run another set of processes in an asynchronous way. The 2nd process doesn't have to callback anything nor is related to the WCF in any way. It just needs to read the table and perform a series of methods and maybe a Web Service call (if there are records of course), but that's all. The WCF service clients consuming the above mentioned service have no idea of this and don't care about it.

I've read about this question in StackOverflow and I also know that a Windows Service would be ideal, but this WCF Service will be hosted on a Shared Hosting (discountasp or similar) and therefore, installing a Windows Service will not be an option (as far as I know).

Given that the architecture is fixed (I.E.: I cannot change the table, it comes from a legacy format, nor change the mechanism of the WCF Service), what would be your suggestion to poll/process this table?

I'd say I need it to check every 10 minutes or so. It doesn't need to be instant.

Thanks.

Was it helpful?

Solution

Cheat. Expose this process as another WCF service and fire a go command from a box under your control at a scheduled time.

Whilst you can fire up background threads in WCF, or use cache expiry as a poor man's scheduler those will stop when your app pool recycles until the next hit on your web site and the app pool spins up again. At least firing the request from a machine you control means you know the app pool will come back up every 10 minutes or so because you've sent a request in its direction.

OTHER TIPS

A web application is not suited at all to be running something at a fixed interval. If there are no requests coming in, there is no code running in the application, and if the application is inactive for a while the IIS can decide to shut it down completely until the next request comes in.

For some applications it isn't at all important that something is run at a specific interval, only that it has been run recently. If that is the case for your application then you could just keep track of when the table was last polled, and for every request check if enough time has passed for the table to be polled again.

If you have access to administer the database, there is a scheduler in SQL Server. It can run queries, stored procedures, and even start processes if you have permission (which is very unlikely on a shared hosting, though).

If you need the code on a specific interval, and you can't access the server to schedule it or run it as a service, or can't use the SQL Server scheduler, it's simply not doable.

Make you application pool "always active" and do whatever you want with your threads.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top