As an application, we sometimes expect that code execution is not entirely driven by Web users' requests. We hope that some specific tasks can be periodically and periodically executed when starting a Web process, this type of work is generally expected to be automatic scheduling or logical scheduling under system control. CS implements related work and designs a framework for basic task scheduling, which allows us to execute tasks driven by non-Web user requests. The task startup framework is usually used when the entire CS is started, that is, what we usually call global. in asax: protected void application_start (Object sender, eventargs e) {jobs. instance (). start (); eventlogs. info ("Cs. web started "," application ", 200);} obtains a singleton instance through the static instantiation function instance of jobs, and the start function of the jobs instance is the details of the startup framework: public void start () {If (joblist. count! = 0) // joblist indicates the number of tasks currently being executed. If multiple tasks exist, you do not need to start these jobs again. csconfiguration csconfig = csconfiguration. getconfig (); // get the configuration if (! Csconfig. isbackgroundthreadingdisabled) // check whether the configuration allows the presence of background threads {// If xmlnode node = csconfig is allowed. getconfigsection ("communityserver/jobs"); // check the job configuration section bool issinglethread = true; // the following code checks whether the single-threaded task xmlattribute singlethreadattribute = node. attributes ["singlethread"]; If (singlethreadattribute! = NULL &&! Globals. isnullorempty (singlethreadattriy. value) & string. compare (singlethreadattribute. value, "false", true) = 0) issinglethread = false; else {issinglethread = true; xmlattribute minutes = node. attributes ["Minutes"]; If (minutes! = NULL &&! Globals. isnullorempty (minutes. value) {// converts the set cycle from millisecond to millisecond try {interval = int32.parse (minutes. value) * 60000;} catch {interval = 15*60000;} foreach (xmlnode jnode in node. childnodes) {// read the configuration information of each task. if (jnode. nodetype! = Xmlnodetype. comment) {xmlattribute typeattribute = jnode. attributes ["type"]; xmlattribute nameattribute = jnode. attributes ["name"]; type = type. getType (typeattribute. value); If (type! = NULL) {// if the task name exists in joblist, do not start if (! Joblist. contains (nameattribute. value) {// The job will be analyzed later. Here a person is started according to the type, and the structure of the task will read the configuration node information jnode job J = new job (type, jnode); joblist [nameattribute. value] = J; If (! Issinglethread |! J. singlethreaded) J. initializetimer (); // initialize timer if it is a multi-thread task }}} if (issinglethread) {// create a new timer to iterate over each job once every 15 minutes singletimer = new timer (New timercallback (call_back), null, interval, interval) ;}} from the above, if a job is single-threaded, it runs scheduling through a single timer instance singletimer of the job instance. if the job is multi-threaded, you must first prepare a timer for each job to execute its own job scheduling. For task scheduling that shares a timer, the callback function is like this: Private void call_back (object state) {_ isrunning = true; _ started = datetime. now; singletimer. change (timeout. infinite, timeout. infinite); // The interval between timer is set to an infinite length. When initializing this job, scheduling of other tasks is prohibited to avoid the trouble caused by re-entry foreach (job in joblist. values) if (job. enabled & job. singlethreaded) // schedules all single-scheduled job jobs in joblist. executejob (); singletimer. change (interval, interval); // you can see that the next scheduling is 15 minutes, that is, a single-threaded task. Is 15 minutes _ isrunning = false; _ completed = datetime. Now;} The timr executed separately is like this: Private void timer_callback (object state) {If (! Enabled) return; _ timer. change (timeout. infinite, timeout. infinite); _ firstrun =-1; executejob (); If (Enabled) _ timer. change (interval, interval); else this. dispose ();} You can see that the final task scheduling, whether it is the default timer of the shared Cs or the timer of each separate job, is the final execution of executejob (). In this function, the real logic of each job is executed. Public void executejob () {onprejob (); // event scheduling _ isrunning = true; ijob = This. createjobinstance (); // ijob interface if (ijob! = NULL) {_ laststart = datetime. now; try {ijob. execute (this. _ node); // The real logic here _ lastend = _ lastsucess = datetime. now;} catch (exception) {This. _ enabled =! This. enableshutdown; _ lastend = datetime. now ;}}_ isrunning = false; onpostjob (); // event scheduling} implements the ijob interface through each job. CS finally instantiates the job through the execution framework and obtains the interface, then, necessary functions of ijob scheduling are implemented to schedule tasks. The job configuration information is as follows: <jobsminutes = "15" singlethread = "true"> <jobname = "sitestatisticsupdates" type = "communityserver. components. sitestatisticsjob, communityserver. components "enabled =" true "enableshutdown =" false "/> ....... <Job singlethread = "false" minutes = "5" name = "emails" type = "communityserver. components. emailjob, communityserver. components "enabled =" true "enableshutdown =" false "failureinterval =" 1 "numberoftries =" 10 "/> ..... <Jobname = "deletestalespamcommentsjob" type = "communityserver. blogs. components. deletestalespamcommentsjob, communityserver. blogs "enabled =" true "enableshutdown =" false "expirationdays =" 30 "/> </jobs> If timer is not required for a task, then we can use the default settings of jobs. We can see that most tasks are singlethread, while emails sets singlethread to false because the mail sending tasks may be frequent. In this way, scheduling is implemented separately, the interval is 5 minutes. You can use the attribute of the job section to customize the job settings. In the current implementation framework of jobs, the settings can be passed to specific job instances to schedule tasks. To add task scheduling in the existing scheduling framework, it is relatively simple: 1. Implement a specific class of the scheduling task and implement the ijob interface. The logic for scheduling and execution is implemented in the execute method. 2. Register in the jobs section of communityserver. config and add attribute as needed to pass the setting information. If you want to Implement Task Scheduling in your project, you also need to: 1. Implement a jobs class, refer to the implementation of CS. 2. Add the jobs configuration section in the config file. 3. Run Gobal. asax to implement the task scheduling configuration reading and scheduling initialization. 4. add your own scheduling tasks and implement the ijob interface. In this way, we can closely associate with the Asp.net application, but the work that needs to be scheduled or triggered without the user's HTTP request is handed over to the scheduling framework. These applications can be used as examples but are not limited to the following: Update global settings, such as global count statistics, analysis, and major event records of applications for some cache operations, it can be executed on a regular basis. For example, we usually have records of PV operations. If a database record is required for each click, the server resources will be greatly consumed and these operations can be cached in global variables, then, the customized job is used to perform the operations of warehouse receiving and resetting the counter.
There are also some time-consuming operations that can be handed over to the job for execution. After analysis, the results are displayed to the access user, avoiding waiting for execution in the HTTP request and occupying valuable HTTP pipeline resources.
