Quartz best practice of open Source scheduling framework

Quartz Best practice of open source scheduling framework

Author: Chszs, reprint should be indicated. Blog home: Http://blog.csdn.net/chszs

Quartz is a Java scheduling framework with the latest version of 2.2.1.
Take the quartz 2.2.1 version as an example, quartz best practices (for production systems) are summarized as follows:

1, skip the update check
Quartz has an "update check" feature built into it, so the quartz project checks the official website every time it starts, quartz whether there is a new version. This check is asynchronous and does not affect the startup and initialization of the quartz project itself.
You can skip the update check in the Quartz configuration file by setting the Org.quartz.scheduler.skipUpdateCheck property to True.

2, Jobdatamap Skills
You should store only the original data types (including strings) in Jobdatamap, which avoids the problem of data serialization and long-running problems.

3, use the merged Jobdatamap
Officially, the Job.execute () method should usually retrieve data from the Jobdatamap found in Jobexecutioncontext rather than directly from Jobdetail.

4. Use Triggerutils
The Triggerutils tool class functions as follows:
1 provides a simpler way to create triggers;
2 provides a variety of methods for creating triggers with scheduler to meet special needs, contrary to the direct initialization of special types of triggers (Simpletrigger, Crontrigger), and then the invocation of various setter methods for configuration.
3 provides a simpler way to create a date-time;
4 provides an auxiliary class to analyze triggers (such as calculating the number of future activations).

5, must not directly write data to the Quartz table
Writes data to a database table through SQL statements, rather than using the dispatch API to write data because:
1 can cause data conflicts (delete data, scramble for data).
2 causes the job to look lost when the trigger's activation time is up.
3 causes the job to not execute when the trigger is activated, and looks "just sitting there".
4) may cause deadlock
5 can also lead to other strange problems and data crashes, etc.

6. Do not point to multiple non-clustered scheduler instances to the same database table
If you point multiple scheduler instances to the same database table, and these scheduler instances do not do cluster configuration, this can occur:
1 can cause data conflicts (delete data, scramble for data).
2 causes the job to look lost when the trigger's activation time is up.
3 causes the job to not execute when the trigger is activated, and looks "just sitting there".
4) may cause deadlock
5 can also lead to other strange problems and data crashes, etc.

7, to ensure that the appropriate number of data source connections
Official recommended maximum number of connections for data sources should be configured to 3 times times the minimum number of worker threads for the thread pool. If you still need additional connections (such as calling the Scheduler API frequently), if you use JOBSTORECMT, the maximum number of connections for unmanaged data sources should be at least 4 times times higher.

8. Avoid scheduling job schedules at the junction of daylight saving time conversion
Simpletrigger triggers are not affected by this.

9, waiting conditions
If all the threads in the connection pool are busy, the long-running job prevents other jobs from running.
If Thread.Sleep () is invoked when the worker thread executes the job, the rest of the job may not be executed because it waits for some conditions, such as when the data record is valid, to execute.
The best solution is to release the worker thread (exit job) and allow the other job to be executed on the thread. The job can reschedule itself, or wait for the other job to schedule it before exiting.

10. Job throws exception
The job execution method should contain a Try-catch code block to handle a variety of possible exceptions.
If the job throws an exception, Quartz usually immediately rerun (it looks like it will throw the same exception again). The best way to do this is to have the job catch all the exceptions it might encounter, handle the exceptions, and then reschedule the job.

11, recoverability and power of
Marked as recoverable, the in-progress job can be automatically rerun after the scheduler expires. This means that the same job may be performed two times.

12. Keep the code simple and efficient in the listener
It is not encouraged to perform a large amount of work within the listener, to perform a job or to complete a trigger, and to activate another job, should be bound to the listener.

13, the listener throws an exception
Each listener (Triggerlistener, Joblistener, and Schedulerlistener) should contain a Try-catch code block to handle a variety of possible exceptions.
If the listener throws an exception, it may cause other listeners to not be notified or to block the execution of the job, and so on.

14. Pay attention to safety
Some developers expose the functionality of the Quartz scheduler through the user interface of the application, which is useful but also dangerous. Because a malicious user can control or destroy your system in this way.