Quartz Job Scheduling Framework[翻译]第六章. Job 存储和持久化 (第二部分)

四. 使用持久性的 JobStore

在很多方面,JobStore 有用内存来存储的,还有些使用某种能长期持久的方式来共享相拟的特征。这不该有什么惊奇的,因为他们都服务于同一目的。

RAMJobStore 一样,特久性的 JobStore 有优点也有其缺点。在你选择持久性的 JobStore 之前应该认真理解其利与弊。这节就来解释它们的区别,以及在什么情况下你会希望使用持久性的 JobStore

目前,Quartz 提供了两种类型的持久性 JobStore,每一种类型都有其独特的持久化机制。

持久性 JobStore = JDBC + 关系型数据库

尽管有几种不同的持久化机制可被 Quartz 用于持久化 Scheduler 信息,Quartz 依赖于一个关系型数据库管理系统(RDMS) 来持久化存储。假如你想用某种别的而不是数据库来持久化存储,那么你必须通过实现 JobStore 接口自己构建它。假定你想用文件系统来持久化存储。你可以创建一个类,这个类要实现 JobStore 接口,在本章中,当我们说 "持久化",我们隐式的是说用 JDBC 来持久化 Scheduler 状态到数据库中

Quartz 所带的所有的持久化的 JobStore 都扩展自 org.quartz.impl.jdbcjobstore.JobStoreSupport 类。

·JobStoreSupport

JobStoreSupport 是个抽象类,并实现了 JobStore 接口,在此章前面就讨论过的。它为所有基于 JDBC 的 JobStore 提供了基本的功能。图 6.1 显示了 JobStore 类型的层次关系。

图 6.1. JobStore 类型层次如图 6.1 所描绘的,JobStoreSupport 实现了 JobStore 接口,是作为 Quartz 提供的两个具体的持久性 JobStore 类的基类。

JobStoreSupport 本该名之为 JDBCJobStoreSupport作为这个类的一个更好的名字本应该是 JDBCJobStoreSupport,因为这个类专门是为基于 JDBC 存储方案而设置的,然而,这个名并没有减损到它为持久性 JobStore 所提供的功能。

因为 JobStoreSupport 类是抽象的,因此 Quartz 提供了两种不同类型的具体化的 JobStore,每一个设计为针对特定的数据库环境和配置:

·org.quartz.impl.jdbcjobstore.JobStoreTX

·org.quartz.impl.jdbcjobstore.JobStoreCMT

这两个持久性 JobStore 前面简单讨论过。但现在,我们来讨论两个版本所需要的数据库。

五. 为 Job 存储使用数据库

Quartz 中的持久性 JobStore 有时候就是指 JDBC JobStore,因为他们基本是依赖于一个 JDBC  驱动和一个关系型数据库通信。持久性 JobStore 会用到许多的 JDBC 特性,包括支持事特,锁定和隔离级别,只列了这几个特性罢。

要是我的数据库不支持 JDBC 呢?假如你的数据库不支持 JDBC,那你肯定是碰到什么问题了。并不能全归咎于你运气不好,只是在这之前你还有很多工作要做。你最好是切换到某一种支持的数据库平台上来。假如你的数据库不支持 JDBC,你将需要创建一个新的实现(实现了 JobStore 接口)。你也许想检查一下 Quartz 用户论坛里的用户,看谁是否已经做了这样的工作,并是否愿意共享他们的代码或者至少告诉你实现的方法。

·持久性 JobStore 所支持的数据库

Quartz 中的持久性 JobStore 被设计能与如下数据库平台一同使用:

    ·Oracle

    ·MySQL

    ·MS SQL Server 2000

    ·HSQLDB

    ·PostgreSQL

    ·DB2

    ·Cloudscape/Derby

    ·Pointbase

    ·Informix

    ·Firebird

    ·大多数别的有完全 JDBC 兼容性驱动的 RDBMS

·独立环境中的持久性存储

JobStoreTX 类设计为用于独立环境中。这里的 "独立",我们是指这样一个环境,在其中不存在与应用容器的事物集成。这里并不意味着你不能在一个容器中使用 JobStoreTX,只不过,它不是设计来让它的事特受容器管理。区别就在于 Quartz 的事物是否要参与到容器的事物中去。

·程序容器中的持久性存储

JobStoreCMT 类设计为当你想要程序容器来为你的 JobStore 管理事物时,并且那些事物要参与到容器管理的事物边界时使用。它的名字明显是来源于容器管理的事物(Container Managed Transactions (CMT))。

六. 创建 Quartz 数据库结构

JobStore 是基于 JDBC 的,它需要一个数据用于 Scheduler 信息的持久化。Quartz  需要创建 12 张数据库表。表的名字和描述在表 6.1 中列出。

表 6.1. Quartz 需要下列表用于所有的 JDBC 的持久性 JobStore
表名 描述
QRTZ_CALENDARS 以 Blob 类型存储 Quartz 的 Calendar 信息
QRTZ_CRON_TRIGGERS 存储 Cron Trigger,包括 Cron 表达式和时区信息
QRTZ_FIRED_TRIGGERS 存储与已触发的 Trigger 相关的状态信息,以及相联 Job 的执行信息
QRTZ_PAUSED_TRIGGER_GRPS 存储已暂停的 Trigger 组的信息
QRTZ_SCHEDULER_STATE 存储少量的有关 Scheduler 的状态信息,和别的 Scheduler 实例(假如是用于一个集群中)
QRTZ_LOCKS 存储程序的非观锁的信息(假如使用了悲观锁)
QRTZ_JOB_DETAILS 存储每一个已配置的 Job 的详细信息
QRTZ_JOB_LISTENERS 存储有关已配置的 JobListener 的信息
QRTZ_SIMPLE_TRIGGERS 存储简单的 Trigger,包括重复次数,间隔,以及已触的次数
QRTZ_BLOG_TRIGGERS Trigger 作为 Blob 类型存储(用于 Quartz 用户用 JDBC 创建他们自己定制的 Trigger 类型,JobStore 并不知道如何存储实例的时候)
QRTZ_TRIGGER_LISTENERS 存储已配置的 TriggerListener 的信息
QRTZ_TRIGGERS 存储已配置的 Trigger 的信息

中表 6.1 中,所有的表都是以前缀 QRTZ_ 开始。这是默认的,但是你可以通过在 quartz.properties 文件中提供一个替代的前缀来改变它。如果你对不同的 Scheduler 实例使用了多套的表,那么改变这个前缀则是必须的。这在你需要用到多个非集群的 Scheduler,但只想用一个单独的数据库实例时也是要做的。

·安装 Quartz 数据库表

Quartz 包括了所有被支持的数据库平台的 SQL 脚本。你能在 <quartz_home>/docs/dbTables 目录下找到那些 SQL 脚本,这里的 <quartz_home> 是解压 Quartz 分发包后的目录。

大约有 18 种不同的数据库平台的脚本。这差不多能覆盖到你所能想出来的任何数据库。假如你的不在其列,你可以使用其中一个已存在的脚本,略做修改以适应你的数据库平台。

要安装必须的数据库表,先打开那个专为你的数据库平台制作的 .sql 文件并用你喜爱的查询工具执行其中的命令。比如说是 MS SQL Server,你需要用数据库所带的查询分析器(Quary Analyzer) 运行文件 tables_sqlServer.sql 中的命令。SQL 命令不负责创建数据库。你还要特别留意 SQL 文件最前面的注释。通常,在运行命令之前都必须执行几条指令。例如,还是 MS SQL Server 的 SQL 文件,你需要修改文件顶端的这条命令,填入数据库名称,在你刚创建它的时候还是一个空数据库。

USE [enter_db_name_here]

SQL 文件创建了必须的表结构,还给表加上了基本的约束和索引。在本章后面,我们会讨论如何通过对表结构做些额外的变动来改进性能。

QuartzFigure6.1.jpg

类别: Quartz. 标签: , . 阅读(1,391). 订阅评论. TrackBack.

Leave a Reply

Be the First to Comment!

avatar
wpDiscuz