.net website BackgroundWorker. Is it a good idea?

I am planing to use BackgroundWorker on my .net site to perform some database maintenance every night at 12:00. Is it a good idea to have asynch proccess monitoring ti开发者_如何学Gome and perform action? I am using sql server express edition so i can't use any scheduling on database side. I also don't want to use windows task scheduler

---

Why don't you want to use the Windows scheduler? That's the most obvious solution - you want to schedule something to happen on a regular basis, after all.

Otherwise, I'd suggest probably using a Windows Service and a timer (System.Timers.Timer or System.Threading.Timer). You'll need to consider the possibility of daylight savings time and things like that - which is one reason to use the built-in scheduler.

I wouldn't suggest that you make this part of an ASP.NET site. It's too tricky (IMO) to think of all the corner cases around AppDomain recycling etc.

---

AFAIK you can't schedule a job using the ASP.NET runtime at all, there is no API that would let you do it. The ASP.NET runtime is a reactive service; it reacts to an HTTP request, serves up a response, then effectively sleeps until the next request. It also reserves the right to create and destroy AppDomains and objects at any time to meet its memory pressure obligations.

Your choices are:

• Windows scheduler
• SQL Server scheduler
• A custom Windows service (which is effectively emulating the Windows scheduler so there's not much point)

If all those options are denied you then I'm afraid you're out of luck. Sorry.

---

No. Use a scheduled task.

---

It's been my experience that trying to do these types of things from a Web app is notoroiously unreliable.

Web servers are far more prone to reset than other servers for a variety of reasons. You'll find that scheduled tasks (even simple batch files that launch SQL scripts, or DLLs that execute managed or unmanaged code) are far more reliable. Further, as Jon pointed out, scheduling them and being able to trust that they've executed when you want them to is a snap and you have a far higher degree of confidence in the scheduling mechanism because you didn't have to build it, test it, and deploy it yourself.

I know that in Jon's comment you've said you won't have access to the server yourself. But if you can, find a way to make a compelling argument to get that access. If this is a critical process, you'll need it. As far as I'm concerned, system integrity--especially when it comes to data--is always a compelling argument.