十三. 改善持久性 JobStore 的性能
当在只有最少量时间做任何相关事情的时候，性能是一个广受人瞩目的课题。作为有经验的开发者，我们知道从项目之初它就成为一个需要考虑的事。
在使用 Quartz 的 JobStore 时，最大的关注面就是有关于与关系型数据库的交互。数据库 I/O(就像文件 I/O) 通常不是很快。你可以通过采取一些措施，如调优 SQL、增加索引和操作表和列等来改善性能。因为性能问题在写 Quartz 框架的时候就已有考虑到，而你又不想在未出现实际的性能问题时扎入到 Quartz 中做些手脚，那么可试图通过配置来解决它，或者尝试所有可能的方式，只要不是维护源代码。最好的消息是 Quartz 是开源的，你完全可以窥入其中了解它做了什么和如何实现的。假如你不喜欢它现有的查询数据库的方式，你有权去修正它。不过，在你采取行动之前，确定检查了 Quartz 论坛上的用户和开发者，看看是否其他人也遇到了相关的问题并浏览推荐的做法。 阅读全文 >>
十二. 为 JobStoreCMT 配置数据源
跟 JobStoreTX 一样，我们需要配置一个 Datasource 才能使用 JobStoreCMT。然而，JobStoreCMT 需要两个 Datasource 而不是像 JobStoreTX 只要一个。其中一个 Datasource 和我们为 JobStoreTX 设置的类同：作为不受管理的数据源。同时呢，我们还需配置第二个数据源，是作为受管理的数据源，它由应用服务器来进行管理。
| 为什么 JobStoreCMT 需要两个 Datasource 呢？JobStoreCMT 的原始作者，Jeffrey Wescott，设计 JobStoreCMT 使用一个标准的 JDBC 连接来做它“自己的工作”，同时，代表客户端(如部署 Job) 的工作在执行时是使用一个在容器控制之下有自身事物的 JDBC 连接。即使 Quartz 处在一个大事物中，这种设计也允许用户与 Quartz 交互，而无需 JobStoreCMT 非得使用应用服务器的事物管理器(例如，经由 UserTransaction) 在做自己内部工作时(如处理已错过执行的 Trigger) 来创建和终止事物。如果是 JobStoreCMT 使用 UserTransation 只给它配置一个数据源，从配置方面来看确实方便。然而，在相比于别的特性需求和改进的必要性时，作此变化并不会成为团队中首要的问题，因而 JobStoreCMT 还是继续要两个数据源。 |
十. 使用数据库存储 Scheduler 信息
·加载 Job 到数据库中
在前面有一节，"使用内存存储 Scheduler 信息"，我们谈到关于在使用 RAMJobStore 时如何加载 Job 和 Trigger 信息到内存中。那么 Job 和 Trigger 又是如何加载到数据库中的呢？存在以下几个方法把 Job 信息存入到数据库：
· 在你的程序中加入 Job 信息
· 使用 JobInitializationPlugin
· 使用 Quartz Web 应用程序
我们在前面的 RAMJobStore 章节中讨论过前面两种途径。当它们用于 JDBC JobStore 时，并没有多大不同，只些许例外。首先，你需要知道，当使用这两个方法式，Job 信息是在数据库中的。甚至在你停止了程序后，这些信息仍然保留在数据库中。甚至是你不在你的程序中使用 JobInitializationPlugin 时，这些信息也还在数据库中。基于这一点，它是会从数据库中找寻 Job 信息。第八章涵盖了 JobInitializationPlugin 和常用的 Quartz 插件。 阅读全文 >>
八. 为 JobStroreTX 创建数据源
当使用持久性 JobStore 时，Quartz 需要一个数据源。数据源扮演着产生数据库连接工厂的角色。在 Java 中，所有的数据源要实现 java.sql.Datasource 接口。Quartz 自身并不提供 Datasource 的所有功能；它只代表了那一职责。默认的，Quartz 能使用另一开源的框架，叫做 Commons DBCP，或者可以通过 JNDI 查找应用服务器中定义的 DataSource。
DBCP 是一个 Jakarta Commons 项目，网址是 http://jakarta.apache.org/commons/dbcp。这个框架的二进制版包含在 Quartz 的发行版中，你应该把它加到你的 Quartz 应用中来。你还需要加入 Commons Pool 库，它也包含中 Quartz 发行版中，是 DBCP 要用到的。
使用 JobStoreTX 时，你必须在 quartz.properties 文件中指定 Datasource 属性。这允许 Quartz 为你创建并管理 Datasource。表 6.4 列示了使用 JobStoreTX 时需要的 Datasource 配置属性。 阅读全文 >>
七. 使用 JobStoreTX
我们首先要讨论的持久性 JobStore 是 JobStoreTX。名字中的 "TX" 代表着 "事物"。我们在前面提过，JobStoreTX 是设计用于想要 Quartz 来管理事物的环境中。例如，假如你正构建一个 J2EE 应用，并且不使用到应用服务器，如 WebLogic 或者 JBoss 等，那么 JobStoreTX 会是持久性 JobStore 正确的选择。
在之前章节中，我们看到配置 RAMJobStore 是多么的容易。我们提到 RAMJobStore 的其中一个优点就是易于配置。我们已经讨论过让数据库准备就绪该做的事情；现在我们讲述使 Quartz 应用支持 JDBC JobStore 需要对它配置些什么。 阅读全文 >>
四. 使用持久性的 JobStore
在很多方面，JobStore 有用内存来存储的，还有些使用某种能长期持久的方式来共享相拟的特征。这不该有什么惊奇的，因为他们都服务于同一目的。
和 RAMJobStore 一样，特久性的 JobStore 有优点也有其缺点。在你选择持久性的 JobStore 之前应该认真理解其利与弊。这节就来解释它们的区别，以及在什么情况下你会希望使用持久性的 JobStore。
目前，Quartz 提供了两种类型的持久性 JobStore，每一种类型都有其独特的持久化机制。 阅读全文 >>
第六章. Job 存储和持久化
Quartz 用 JobStores 对 Job、Trigger、calendar 和 Schduler 数据提供一种存储机制。Scheduler 应用已配置的 JobStore 来存储和获取到部署信息，并决定正被触发执行的 Job 的职责。所有的关于哪个 Job 要执行和以什么时间表来执行他们的信息都来自于 JobStore。本章就来看 Quartz 中可用的各种类型的 JobStore，和如何使用他们，以及哪一个能适应你的需求。
| "罗马非一日建成" 道格拉斯.亚当斯，《宇宙环游指南》 |
一. Job 存储 阅读全文 >>
六. 介绍 Quartz Web 程序
早期的 Quartz 框架开发者意识到一个 GUI 对于某类用户群体是必需的。几年前，一个 Web 应用被创立，它可用于管理 Quartz 框架。虽说是历经了几年有相当投入的开发，但不得不说的，总是时断时续的。
近来出现有更多的要求对这个应用的更新与支持，因而又重新吸引了新的开发者自愿的工作并使之保持不断更新。这个应用就是知名的 Quartz Web 程序。(译者注：实际上这个应用程序基本驻步不前，当前版本还是 RC-1 2004-06-26 22:00 的，仅作参考来应用) 阅读全文 >>
五. 使用 ServletContextListener
很值得一提的是你可以配置和集成 Quartz 到 Web 应用的另一种方式。从 2.3 版本的 Servlet API 开始，你能创建监听器，由容器在其生命周期中的某个特定时间回调。其中的一个监听器接口叫做 java.servlet.ServletContextListener，它包括有两个方法：
public void contextInitialized(ServletContextEvent sce);
public void contextDestroyed(ServeltContextEvent sce);
容器会在启动和关闭的时候相应的调用这两个方法。这就可以在 contextInitialized() 方法中初始化 Quartz Scheduler，并通过 contextDestroyed() 方法关闭它。代码 13.5 描述了这种用法： 阅读全文 >>