quartz 定时任务.docx

1.触发器的监听器和作业的监听器（TriggerListenersJobListeners）Listener是我们创建用于监听Scheduler中关于事件发生情况的对象，其中TriggerListener接收涉及Trigger事件的情况，JobListener接收涉及Job事件的情况。l Trigger的事件： Trigger触发、Trigger过时触发和Trigger触发的完成。l Job的事件：Job的执行通知和Job的完成通知。要创建Listener，只需简单的实现org.quartz.TriggerListener或org.quartz.JobListener接口，接着运行时把Listener注册到Scheduler中即可，在注册过程中需要为创建的Listener命名，Listener可以注册为全局的和非全局的，全局的Listener接收所有Trigger/Job的事件，非全局的Listener只接收指定设置的Trigger/Job事件，把JobListener注册到Scheduler的方法如下：scheduler.addGlobalJobListener(myJobListener)或scheduler.addJobListener(myJobListener)；2调度监听器（SchedulerListeners）SchedulerListener与TriggerListener和JobListener类似，SchedulerListener只接收涉及Scheduler自己的事件通知，而与指定设置的Trigger/Job无关；有关Scheduler的事件包括：Job/Trigger的增加、Job/Trigger的删除、Scheduler中一系列严重的事件和Scheduler的关闭等事件；SchedulerListener的创建和注册与其他类型的Listener很相似，但是它没有区分全局和非全局的情况，只要实现了org.quartz.SchedulerListener接口的对象都是。3.作业存储（JobStores）JobStore负责跟踪我们对Scheduler进行配置的有关Job、Trigger和Calendar等信息的数据；选择适当的JobStore对我们的Quartz Scheduler实例是很重要的，幸运的是，当我们理解了不同类型JobStore时，就可以很容易地对JobStore进行选择，我们可以通过对SchedulerFactory创建Scheduler实例所引用的配置文件中的属性进行声明，采用哪种JobStore。3.1 RAMJobStoreRAMJobStore是使用JobStore最简单的一种方式，它也是性能最高效的，顾名思义，JobStore是把它的数据都存储在RAM中，这也是它的快速和简单配置的原因；RAMJobStore的缺点是：当我们的应用系统因为系统的崩溃而丢失了所有有关Scheduler的信息时，采用RAMJobStore方式将无法恢复原先Scheduler中有关Job和Trigger的设置；对一些应用来说，这是可以接收的，但是对其他一些应用来说，这就不是所期望的。3.2 JDBCJobStoreJDBCJobStore也是一种相当有名的JobStore，它通过JDBC把数据都保存到数据库中，所以在配置上会比RAMJobStore复杂一些，而且不像RAMJobStore那么快，但是当我们对数据库中的表的主键创建索引时，性能上的缺点就不是很关键的了。JDBCJobStore几乎可以连接所有的数据库，广泛使用的数据库基本上有Oracle、MySQL、MS SQLServer 2000、HSQLDB、PostreSQL和DB2。使用JDBCStore，我们必须首选创建一系列的数据库表，为了提供给Quartz使用；我们可以在docs/dbTables目录中找到创建表SQL脚本文件，需要注意的是：在这些脚本中所创建的表都以“QRTZ_”为表名的前缀，如：QRTZ_TRIGGERS和QRTZ_JOB_DETAIL；我们可以对表名的前缀进行任意的修改，只要配置文件中有关前缀的属性值与实际的数据库表的前缀一致即可；采用前缀的方式可以在同一个数据库中保存多个Scheduler实例的数据，通过不同的前缀进行区分；我们一旦完成了数据库表的创建，在我们配置和启用JDBCJobStore之前，需要决定在我们的应用中采用哪一种类型的事务；如果我们在执行Scheduling命令（如：增加和删除Trigger）时不需要关联到其他的事务中，我们就可以采用JobStoreTX的方式让Quartz管理这个事务，一般情况下都是采用JobStoreTX的方式来管理事务的。如果我们应用中需要Qua