Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been using a single scheduler to handle all my scheduled tasks (Quartz.Net). I'm starting to rethink how this operates because if I need to update 1 task, I have to stop the entire process, release the update, and start it back up.

My Question: Is it better to have many Windows Services running individual tasks (or groups of similar tasks) or 1 Service running all of the tasks (my current set up)?

share|improve this question
    
The only reason not to, other than clarity and ease of code maintenance into the future, would be that if any kind of conflict can arise from your 1..N schedulers all running their tasks simultaneously then you should not. –  Patrick Hughes Aug 2 '13 at 17:19
    
I assume you mean "The only reason not to run as a single scheduler..."? –  MattB Aug 2 '13 at 18:02
    
Is there any specific reason that you don't want to use the scheduler built into the server? It has become consistenly better with every NT/WServer release. msdn.microsoft.com/en-us/library/windows/desktop/… –  TimG Aug 19 '13 at 12:36
    
Based on what I've read about the built in scheduler, I don't have the granularity of exactly when I want to run something (once a minute, etc.) –  MattB Aug 26 '13 at 16:40
add comment

2 Answers

up vote 1 down vote accepted

I've spent a bit of time recently with Quartz.NET, and I can share some of the experiences we had. My scenario covered a single process (windows service) that was responsible for updating the existing schedule (using details downloaded as XML from a server). The service process also covered most of the functionality that could be triggered.

I think the key factor here is what you mean by "updating" a task. Do you mean simply altering scheduling details (what tasks to run, when to run them etc), or the actual binaries involved in executing the task? If you're expecting frequent updates to binaries and features, then a single monolithic model is probably not right for you. If you are only expecting frequent updates to when and what task should run, then it's worth centralizing the management of the tasks and scheduling.

Trigger groups work nicely for dividing up and managing various job types. This makes the CRUD against the in memory schedule much cleaner. For example, you can get all the jobs in a group fairly easily

share|improve this answer
add comment

I've never used Quartz.NET, but I thought it was set up to allow you to modify job configurations simply by editing a config file and/or dropping in a new DLL, and changes would be picked up immediately.

If that's not the case, then something like that seems like a good approach to me. For example, you can have a separate DLL for each job, with a class that implements a common interface. When a job is scheduled to fire, dynamically load the DLL, use reflection to retrieve an instance of the job, and execute it. So if you need to change a job, you'd simply drop a new DLL in, and the next time it picks it up, it will be the new code.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.