七. 线程在 Quartz 中的用法
线程与 Quartz 来说尤为重要，因为 Quartz 就是设计为支持同时运行多个 Job。为达到此效果，Quartz 非常倚重于内建于 Java 语言的线程，借助于自己的类和借口还有所增强。你已经在本章或前面章节中看到过这方面的例子。
当 Quartz Schduler 首次由某个工厂方法创建时，工厂配置了 Scheduler 会在它的整个生命周期中用到的几个重要的资源。其中一些重要的资源是与线程相关的。
·主处理线程：QuartzSchedulerThread
Quartz 应用第一次运行时，main 线程会启动 Scheduler。QuartzScheduler 被创建并创建一个 org.quartz.core.QuartzSchedulerThread 类的实例。QuartzSchedulerThread 包含有决定何时下一个 Job 将被触发的处理循环。顾名思义，QuartzSchedulerThread 是一个 Java 线程。它作为一个非守护线程运行在正常优先级下。 阅读全文 >>
5. 易失性、持久性和可恢复性
这三个属性有些类似的，由于它们影响的都是 Job 的运行时行为。我们下面依次讨论它们。
·Job 的易失性
一个易失性的 Job 是在程序关闭之后不会被持久化。一个 Job 是通过调用 JobDetail 的 setVolatility(true) 被设置为易失性的。
| 当你需要持久化 Job 时不应使用 RamJobStore RamJobStore 使用的是非永久性存储器，所有关于 Job 和 Trigger 的信息会在程序关闭之后丢失。保存 Job 到 RamJobStore 有效的使得它们是易失性的。假如你需要让你的 Job 信息在程序重启之后仍能保留下来，你就该考虑另一种 JobStore 类型，比如 JobStoreTX 或者 JobStoreCMT。它们会在第六章“作业存储与持久化”中讲到。 |
Job 易失性的默认值是 false. 阅读全文 >>
3. 管理 Scheduler
除了启动 Scheduler, 在应用的生命周期中你也许还要执行 Scheduler 的别的一些操作。这些 Scheduler 操作包括查询、设置 Scheduler 为 standby 模式、继续、停止。很多情况下，当一个 Scheduler 启动后，除让它运行之外你不需要对它做任何事情的。在某些情形下，你也可能会要临时的终止 Scheduler 而转入到 standby 模式。
·启动 Scheduler
启动一个 Scheduler 也不总是一目了然的。当你有了 Scheduler 的实例，并得到正确的初始化，你的 Job 和 Triiger 也已注册上去了，你只需要简单的调用 start() 方法：
第四章. 部署 Job
在上一章中，你首次尝试使用了 Quartz 来部署 Job。无可否认地，那些 Job 都不是很复杂，但这个不是重点。你应该轻松的对如何构造并部署 Job 有了相当的了解，更重要的是，由此热情的希望学得更多的东西。在本章中将会继续给你讲述。
第四章将带领你深入到 Quart 框架的核心部分。可证明的是，这一章对于阅读和理解本书是非常之重要的。调度器(Scheduler) 是此框架的心脏。本章关注于如何使用 Scheduler 来管理你的 Job；如何创建并关联触发器以使 Job 能被触发执行；以及如可选择 calendar 为给定的时程安排提供更多的灵活性。
·在 J2EE 应用服务器中运行 Quartz
作为 J2EE 客户端运行 Quartz 比运行为外部 J2SE 应用程序稍显繁琐。这主要是因为部署一个应用到容器中有点了儿复杂，J2EE 规范对容器中的组件会有些约束。其中最大的原则之一就是涉及到该由谁来创建线程。因为 J2EE 容器有责任去管理所有资源，所以它并非允许谁想谁就能创建线程的。假如是这样的话，容器就会要更艰难的去管理环境和保证一切稳定性。Quartz 会创建自己的工作者线程，所以你必须依照一些步骤来保证它能正常的运转。
确保代像代码 10.1 那样的一个无状态会话 Bean 已部署到容器中。最简单的部署 Quartz 到容器中的方式是构建一个包含所必须文件的 WAR 包，然后使用管理工具或 Eclipse 部署这个 Web 应用到容器中。 阅读全文 >>
Java 2 平台企业版定义了基于组件的企业应用开发标准。不管你是否倾向于使用一种开源的 J2EE 服务器，比如 JBoss 或 Geronimo，或者你更希望得到可靠安全的商业服务支持，比如 WebSphere 和 WebLogic，你都能在那些应用服务器中使用几种不同的部署方式使用 Quartz。本章给你示范了在 J2EE 应用服务器中以不同策略部署 Quartz，你也会看到 Quartz 框架更加丰富了 J2EE。
一：假如我有 J2EE，为什么还需要 Quartz?
自从 20 世纪 90 年代末期 J2EE 首次登上舞台以来，开发人员就被某些规格决议和一些表面看来明显缺失的特征所困惑。这没必要去批判规格的制定者，更多的是说明了当有不同意见和议程的独立团体，在尝试达成统一的优先级时，就像联合国进行决议时那样，并不如所想像的那样好。许多必须的特征获得认可，但是一些关键的特征被略去留待以后加入。其中一个让早期规范遗漏的关键特征就是定时器服务。 阅读全文 >>
6. 创建 RMI 客户端
你需要创建一个客户端，用来调用远程 Quartz 调度器上的方法。客户端会同 RMI 注册服务器进行通信，进而定位到远程调度器对象，然后就能够调用其上的方法了。这些方法包括有暂停和停止调度器、部署和卸下 Job，和执行所有其他对与远程客户端可见的方法。
·配置 Quartz RMI 客户端
类似于表 9.1 所示服务端的配置，表 9.2 所列出的属性也是必须加到 Quartz RMI 客户端的。这两份属性列表必须分别应用到服务端和客户端的。 阅读全文 >>
4. 创建 Quartz RMI 服务端
你务必按几个步骤来配置 Quartz 来使用 RMI。其中的一些步骤会在创建 Quartz RMI 服务端用到，还有些步骤会在 Quartz 客户端连接服务端。我们先来阐述服务端的配置步骤。
·配置 Quartz RMI 服务端
第一步就是修改要部署到 Quartz RMI 服务端的 quartz.properties 文件。当在 Quartz 中使用 RMI，你还必须添加几个新的属性。表 9.1 包括了完整 RMI 属性列表。 阅读全文 >>
第九章. 使用 Quartz 的远程方式
以独立方式运行的 Quartz 应用程序，仅限于在 JVM 内部访问调度器。和其他任何 J2SE 程序一样，不使用其他某种机制的话，是决不允许从外部访问 JVM 中的对象的。
幸运的是，有几种技术(机制) 可让你做到这一点。Quartz 框架很好的支持其中一种机制－－远程方法调用(RMI)。本章就是关注于如何部署 Quartz 为一个 RMI 服务，以便于你能够从 JVM 外部访问到调度器。这样做有几个好处，这也是我们本章要讨论内容。 阅读全文 >>
4. 打包 Quartz 应用程序
让我们最后简单讨论打包一个用到了 Quarts 框架的应用程序的流程，也以此来结束本章的内容。
·Quartz 第三方依赖包
从 1.5 版的发行包开始，你会看到一个 <QUARTZ_HOME>\lib 目录，在这个目录，你会发现几个子目录：
·<QUARTZ_HOME>\lib\core ·<QUARTZ_HOME>\lib\optional
·<QUARTZ_HOME>\lib\build 阅读全文 >>