I have this question from a client, to run some database scripts on a daily or biweekly basis, depending on the type of period. They have defined a 'busy' period and a 'quiet' period. They are using shared hosting for their applications and they can't add SQL Server jobs to their database.
What I want to do is create a windows service, which is configurable using a config file, containing the different periods and their intervals.
This service is checking the current time and date versus the scheduled periods in the configuration file and will execute a sql server stored procedure once the interval matches
My question: Is there a better way to do this kind of scheduling without sql server or do you know if an existing, more generic (free) solution already exists?
[Edit]
I can't use windows task scheduler since their quiet period is during winter and their busy period is during summer. With task scheduler I'd have to modify the scheduled tasks manually twice a year. That's now what I nor my client wants.
[/Edit]
Thanks
You could use "Scheduled Tasks" feature of windows to start some console application whenever it is required.
If you want to create your own scheduling solution, then I'd recommend to have a look at Quartz.NET, which offers the same flexibility as the windows task scheduler.
Why not use the task scheduler and then every time your application gets started, it checks it's own schedule to work out whether or not it needs to do something.
So you could use the task scheduler to start your application every 15 minutes. When your application starts up it uses it's own configuration file to work out whether or not it needs to do something.
You could also use this to get your application to stop any currently running versions of your application to kill any long running tasks!
Related
I know that creating a Windows Service allow us to run background jobs without having to login to the machine. while .exe files can be run when users login to their PC and click on the .exe file (require user to be login).
But now let say i create a .exe file and i schedule it to run using windows Task Scheduler. where i can specify to run the task even when the user is not login.. so in this case what will be the real difference between :-
Having a .exe which is scheduled to run using task scheduler?
and between having a windows service ?
Thanks
Task Scheduler is generally suitable for processes which carry out periodic or occasional tasks, anything from once per minute, to "at logon" or "once per year". They can be made to effectively run continuously too, but that's really an abuse of the system.
Task Scheduler can also run processes in the context of the logged-on user, and such processes can interact with the user.
Services are generally suitable for processes which run continuously, such as those servicing devices, or providing network services.
Services generally cannot interact directly with the user. Where they need to do this, there is generally a user program which communicates with the service via some sort of RPC, such as DCOM, MSRPC or something else.
There isn't really anything a service can do which a program started by Task Scheduler cannot, or vice-versa: These capabilities depend on the login identity that the program runs under, not on how they are started.
Summary:
If you want a continuous process which provides services to the network, you probably want a service.
If the process is slow to start up, but cheap to keep going once running, you probably want a service.
If you want to perform periodic tasks of any kind, you probably want a scheduled task.
If the process is expensive or intensive in CPU or disk usage, you probably want to rewrite it so that it isn't.
As long as your software do whatever it has to do correctly, there will not be any differences. It all depends in what approach you want to give to your development. I usually try to involve the less components I can in this kind of solution just to make easier the troubleshooting and manteinance. For example If you install your .exe and configure it as a scheduled task, whenever it fails you will have to check not only what is inherent to your software but all what is involved in a scheduled task (user, schedules, triggers, services), and you not always will be able to control that, as your application may be installed on a server you do not have full rights to do what you want.
Also, take in consideration that every scheduled task depends on the Task Scheduler which is a service himself.
So to resume: The advanteges of creating a Job IMHO, is avoiding to recreate all the scheduled-triggered logic that might be a headache to develop if you have not done it before. And it is not better to reinvent the wheel. In the other hand, if you have some clear task that can be done with a Timer then it will probably be a better option just to create a Windows Service.
I would like to add here that windows service (schedule tasks) deployment is in developers hand. A developer can write a code to do change the process execution time at any point of time.
At other hand process run through "task scheduler " are dependent to the server admin. Developer has to guide the admin about what time scheduler must run. If there is any requirement to run the process at some irregular time, they have to approach to server admin, either to run the .EXE manually for now and also change the scheduler time. In other case admin only need to restart the service, he will not have any concern about the time!!!
I've been building a web service to synchronize data between SalesForce and Zendesk at my company. In the process of doing so, I've built several optimizations to drastically reduce execution time, such as caching some of the larger datasets that are retrieved from each service.
However, this comes at a price. When caching the data, it can upwards to 3-5 minutes to download everything through SalesForce and Zendesk's APIs.
To combat this, I was thinking of having a background worker that automatically cached all the required data every day a midnight. However, I'm not sure what the best method of doing this would be.
Would it suffice to build a class that merely has a worker thread that checks every several minutes to see if it is after midnight, and activate it on launch from Global.asax. Or is there some sort of scheduler already in existence?
EDIT
There seems to be some division between using something like:
FluentScheduler or Quartz.net to house everything within my applications.
Versus using something like windows task scheduler and writing a secondary application to call a function of my application to do so. It seems that using a third party library would be more simple, but is there any inherent benefit to using the Windows Task Scheduler.
I think you want to add your data caching logic to a project of type "console application". You'll be able to deploy this to your server and run it as a scheduled task using windows "Task Scheduler". If you've not worked with this project type or scheduled tasks before there are stack overflow questions which should help here, here, and here. You can add command line parameters if you need and you should have a look at adding a mutex so that only one instance of your code will ever run at once.
add an endpoint that will know how do it and use the windows task scheduler to call that new caching endpoint.
I am creating a web application in which I need to allow the user to schedule the excecution of a task.
I have gone through the various threads for scheduling the task but all of them are using windows service that I am not aware of. Moreover I cannot install visual studio in the server systems due to budget constraints.
Is there a way to create a method that runs a scheduler in a background thread in the asp .net application.Any code sample will be of great help.
That's not the way to go. If you need a scheduled task you should create a console application and run it using the Windows task scheduler.
You could create an application that sends an email to the user with a link to the page where the task is supposed to be done.
One thing to understand is that ASP.NET is intended to service requests from the network.
Everything in it is geared towards that. So, yes, you can run background tasks, but there are a number of caveats and gotcha's.
For instance, IIS will shut down your ASP.NET application if it does not receive any requests for some period. Also, your Application may be restarted without warning, if it detects changes to the file system. So, running code will be aborted.
That's not to say you can't work around these, but it's really not the best fit for scheduled task execution.
Your best bet would be to store the details of the task in a database, and then using either a single always-running Windows Service (really not that difficult to do, there are plenty of examples), or a console application (as suggested) scheduled manually to run regularly, to execute these tasks.
You may find that a library such as Quartz.NET may be of help scheduling/running these tasks.
My issue is pretty simple.
I have an application that should be executed automatically once a day. I have no prior experience with this kind of scenario (some time ago I worked with IBM Control-M but guess that it is way more complete, complex and expensive =))
I thought about two possible solutions:
Creating a Task inside Windows Task Scheduler, which would execute the application;
Implement the application as a Window Service which would run 24/7, but only would perform the needed actions depending on the current time.
Which are the advantages/disadvantages of each approach?
Is there another way to do this?
Thanks in advance.
If it only executes once a day (or so) then just do it as a regular command line app that is executed by the windows task scheduler. Task scheduler already has all of the UI necessary to determine when to kick off the program, pass in parameters and anything else related to the scheduling of the task.
The only real reason to do this type of function as a windows service is if it needs higher execution resolution than once a minute. However, the main downside to a windows service is that you would have to manage the logic for how often/when to kick it off. Another one is that the app is always running, which leaves open the possibility for leaked memory if your code has issues.
On Unix/Linux you would use a cron job schedule a task to be executed. MS Windows' version is called the Task Scheduler and it is already a service that run 24/7 and performs the needed actions depending on the time.
Create a repeating task with the Task Scheduler to run your application. Creating, installing and configuring a service application is not exactly trivial. It's a much more involved process than creating a standard Forms or command line app and you don't need to do it anyway.
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-csharp/70633/Waitable-Timer-in-C
Another library that might be of interest is Quartz.NET
I need to implement a windows service that performs database import, and that once a month.
The program receives data via e-mail, and will import them at the end of each month.
Is there a better way than set the program to sleep for max_integer seconds/miliseconds repeatedly ?
I would not do it as windows service. I would run it as a scheduled task.
Your service will just be sleeping for a month and is just a a waste of resources. Let the OS keep track of the time and start your application to do the once a month processing.
If you can avoid writing a window service, you'll make your life easier - scheduled tasks may be a better option here. Windows services are best used for things where there is some constant background activity that needs to happen - not for running tasks over long timescales.
However, if you must make this a windows service, then you don't want to set a long-timer sleep timeout. That's most definitely a problematic approach. What happens if your application is restarted? How will it know how long it's been sleeping for? Or what if the thread is restarted?
A better approach is to write a record somewhere in the database that identifies when the next import should happen as a date/time. You windows service can wake up periodically (every few minutes or hours) and see if the current date/time is greater than that value. If it is, run the import and update the next run date in the database to the next time to run.
If your app is restarted, you simply read the value back from the database and continue as before.