Shulou(Shulou.com)06/01 Report--

How to understand the JobStore interface in Quartz, many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Org.quartz.spi.JobStore is the top-level interface class for task storage

Org.quartz.simpl.RAMJobStore is a memory storage mechanism implementation class

Org.quartz.impl.jdbcjobstore.JobStoreSupport is an abstract class based on JDBC database storage

Org.quartz.impl.jdbcjobstore.JobStoreCMT is a database storage implementation class that is managed by the application container

Org.quartz.impl.jdbcjobstore.JobStoreTX is a database storage implementation class that is not managed by application container transactions.

Org.quartz.jobStore.class = the concrete implementation class mentioned above

Configure the above code in quzrtz.properties to tell quartz which storage mechanism we use

Compared with the memory storage mechanism, the advantage of using memory storage mechanism org.quartz.simpl.RAMJobStore is that the storage and reading speed of tasks is very fast, which is very different from database persistence, and the framework is easy to build and can be used out of the box. Its disadvantage is that when the Quartz program or application stops, the accompanying data in memory will be reclaimed, and data such as tasks will be permanently lost. Database storage mechanism org.quartz.impl.jdbcjobstore.JobStoreTXTX is the meaning of things. This storage mechanism is used for Quartz transaction management independent of the application container. If it is a data source managed by Tomcat container, then the things we define will not be propagated to the Quartz framework. Generally speaking, no matter whether the business code of our Service service is executed successfully or not, as long as the database operation of Quartz API is called in the code, the task status will be permanently persisted, and even if the business code throws the runtime exception task state, it will not be rolled back to the previous state. The full name of org.quartz.impl.jdbcjobstore.JobStoreCMTCMT is Container Managed Transactions, which means that the container manages things, that is, let the application container host things. It is assumed that the application container is Tomcat, and both the project and Quartz are data sources configured using Tomcat, then the same thing can be shared in the code of the project and Quartz. Regardless of whether the business code or Quartz throws an exception, all data operations in the Service service will be rolled back to the original state. The biggest difference between JobStoreCMT and JobStoreTX is that JobStoreCMT needs to configure two data sources, one that is managed by the application container and the other that is not managed by the application container. Here you need to think about why you need two data sources. My personal understanding is that data sources that are not managed by the application container are used to "add, delete, modify and check" within Quartz. If a trigger has been invalidated, then the trigger will be automatically deleted and submitted within the Quartz framework without the developer's project code to deal with, all managed internally by Quartz. Which storage mode should be chosen?

Under what circumstances do you use RAMJobStore memory storage?

Based on the experience in development,    found that some tasks are started with the start of the project, even if the project is closed or the system goes down, it doesn't matter, because the task will start again when the project is restarted. If only such tasks exist in the project, then you can store them in memory. There are several common ways to start a project, the first is to implement the ServletContextListener listener interface, and then write the hard code to start the Job in the contextInitialized () method of the interface implementation class; the second is to start the task through the XML configuration file of Quartz.

Under what circumstances do you use JobStoreTX database storage?

When   uses this method, it should be noted that if you need to create a Job in a business code, write the code that creates the Job at the end of the service code to ensure that the business code runs successfully and does not throw an exception before starting Job. If you fail to start Job, throw a runtime exception to cause the business code to be rolled back.

Example:

@ Transactionalpublic void demoService (TaskStore taskStore) {/ / execute insert business operation taskStoreService.insert (taskStore) first; / / perform update business operation taskDetailService.update (taskDetail); / / finally start scheduled task QuartzUtils.addJob ("testName", DemoJob.class, "0 *?");}

Note that the addJob () method in the example catches the exception, re-encapsulates it, and then throws the run-time exception, in order to ensure that the business code is rolled back in the event of an internal Quartz error.

Under what circumstances do you use JobStoreCMT database storage?

The difference between    JobStoreCMT and JobStoreTX has been described earlier, and I have not used this approach in a project in the actual development process. JobStoreTX is usually used. If you have strict management of things in your project, it is recommended to use JobStoreCMT storage.

@ Componentpublic class JobFactory extends AdaptableJobFactory {@ Autowired private AutowireCapableBeanFactory capableBeanFactory; @ Override protected Object createJobInstance (final TriggerFiredBundle bundle) throws Exception {/ / calls the parent class's method Object jobInstance = super.createJobInstance (bundle); / / injects capableBeanFactory.autowireBean (jobInstance); the function of this class is to leave the instantiation of Job to IOC. The problem is that the instantiation of Job objects takes place in Quartz, and the injected entity classes are in the Spring container, so you cannot inject Srping container entity classes in job. Solution: by bringing Job Bean into the management of the Spring container, the Spring container can automatically assemble the required dependencies for Job Bean. How to include: the creation of Job is created through JobFactory. JobFactory is responsible for generating instances of the Job class. JobFactory has two implementation classes: AdaptableJobFactory and SimpleJobFactory. The custom factory class JobFactory inherits from AdaptableJobFactory. The Job is instantiated by calling the method createJobInstance of the parent class AdaptableJobFactory. After the instantiation of Job, call your own method to automatically assemble the properties of the created Job instance and bring it into the management of the Spring container. (included through AutowireCapableBeanFactory). Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.