1 触发器的监听器和作业的监听器（TriggerListeners&JobListeners）
Listener是我们创建用于监听Scheduler中关于事件发生情况的对象，其中TriggerListener接收涉及Trigger事件的情况，JobListener接收涉及Job事件的情况。
<!--[if !supportLists]-->l <!--[endif]-->Trigger的事件： Trigger触发、Trigger过时触发和Trigger触发的完成。
<!--[if !supportLists]-->l <!--[endif]-->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 RAMJobStore
RAMJobStore是使用JobStore最简单的一种方式，它也是性能最高效的，顾名思义，JobStore是把它的数据都存储在RAM中，这也是它的快速和简单配置的原因；RAMJobStore的缺点是：当我们的应用系统因为系统的崩溃而丢失了所有有关Scheduler的信息时，采用RAMJobStore方式将无法恢复原先Scheduler中有关Job和Trigger的设置；对一些应用来说，这是可以接收的，但是对其他一些应用来说，这就不是所期望的。
3.2 JDBCJobStore
JDBCJobStore也是一种相当有名的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的方式来管理事务的。
如果我们应用中需要Quartz与其他事务一起运行（如：J2EE应用服务器），就需要采用JobStoreCMT的事务管理方式，这样Quartz将会让应用服务器容器管理事务；
最后一个难题是JDBCJobStore中有关连接数据库的DataSource的设置，Quartz属性中包含了Datasource的几种配置方法，一种是采用Quartz创建和管理DataSource的方式，提供了数据库连接的所有信息；另一种是Quartz使用应用服务器（Quartz运行当中的应用服务器）管理的DataSource，通过采用提供JDBCJobStore的JNDI名字的方式；有关配置属性的详细信息，可以参考“docs/config”目录中的配置文件。
为了使用JDBCJobStore，我们首选需要设置Quartz配置文件中JobStore类属性值为org.quartz.impl.jdbcjobstore.JobStoreTX或为org.quartz.impl.jdbcjobstore.JobStoreCMT，具体设为哪个值可根据我们的应用的需要及结合上面对JobStoreTX和JobStoreCMT的解析；比如：org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX；
下一步我们需要JobStore的DriverDelegate属性，DriverDelegate是负责执行所有与JDBC有关的处理，需要选择与指定数据库对应的Delegate；StdJDBCDelegate是使用一般的JDBC代码（和SQL语句）来执行处理的Delegate，当我们所使用的数据库没有对应的delegate时，可以试着使用StdJDBCDelegate；在org.quartz.impl.jdbcjobstore包或子包中可以找到其他的delegate，其他的delegate大概包含：DB2v6Delegate（用于DB2 version 6和更低version的）、HSQLDBDelegate（用于HSQLDB）、MSSQLDelegate（用于Microsoft SQLServer 2000）、PostgreSQLDelegate（用于PostgreSQL 7.x）、WeblogicDelegate（用于使用Weblogic的JDBC驱动程序）和OracleDelegate（用于Oracle8i和9i）；
一旦选定delegate后，需要对driverDelegateClass属性进行设置：org.quartz.jobStore.driverDelegate = org.quartz.impl.jdbcjobstore.StdJDBCDelegate；
接着我们需要向JobStore声明数据库表名的前缀，通过tablePrefix进行设置：org.quartz.jobStore.tablePrefix = QRTZ_；
最后我们需要设置JobStore将使用哪个DataSource，在Quartz属性配置文件中也需要定义DataSource属性，如：org.quartz.jobStore.dataSource = myDS。