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 为给定的时程安排提供更多的灵活性。
题前说明：本文所做的测试是基于 WAS5.1 的，若是其他 WAS 版，请具体调整，或参考相应版本的红皮书。
WebSphere Application Server (WAS) 确实给我们提供了一个很方便的管理控制台，可以手工很轻松的部署应用程序，管理服务器；有得亦有失，因为它不能像其他很多应用服务器那般拷贝文件的方式进行部署，所以给像 DailyBuild 那样全自动化的过程制造了一些障碍。
其实 WAS 也提供了接口（SOAP 和 RMI）可通过脚本来完成对服务器及应用程序的管理，只是使用起来稍显麻烦，还得钻研一番。你可以采用三种途径来使用 WAS 的接口： 阅读全文 >>
说明：以为转贴，原文 http://tb.blog.csdn.net/TrackBack.aspx?PostId=1930730, 因见此文对目前项目帮助甚大，故直接转载文章内容，而不只是收藏，并保留原文格式，感谢作者分享的宝贵经验。
您可能需要定制 Linux 系统，以提高服务器的性能。 下面，将向您介绍调整配置的技巧。 请牢记，这些系统可能会变化，从而导致这些建议过时，并导致您的结果有所不同。
在您为改善性能而进行任何更改之前，请确保已经对当前性能进行了度量。不管您是否关心事务执行速度、响应时间、最大并发用户数或其他一些性能条件，都需要在更改前后，进行足够准确地度量，以了解更改调优参数是否有效。 阅读全文 >>
·在 J2EE 应用服务器中运行 Quartz
作为 J2EE 客户端运行 Quartz 比运行为外部 J2SE 应用程序稍显繁琐。这主要是因为部署一个应用到容器中有点了儿复杂，J2EE 规范对容器中的组件会有些约束。其中最大的原则之一就是涉及到该由谁来创建线程。因为 J2EE 容器有责任去管理所有资源，所以它并非允许谁想谁就能创建线程的。假如是这样的话，容器就会要更艰难的去管理环境和保证一切稳定性。Quartz 会创建自己的工作者线程，所以你必须依照一些步骤来保证它能正常的运转。
确保代像代码 10.1 那样的一个无状态会话 Bean 已部署到容器中。最简单的部署 Quartz 到容器中的方式是构建一个包含所必须文件的 WAR 包，然后使用管理工具或 Eclipse 部署这个 Web 应用到容器中。 阅读全文 >>
ZeroTurnaround 宣布 JavaRebel 1.0 最终正式版发布。JavaRebel 通过即时重加载有改变的类，从而避免了应用服务器的重新部署。此次版本与第一个公开发行版加入了以下改进：
·简化了安装。现在 Java 5 中安装 JavaRebel 只需要加上 "-noverify -javaagent:javarebel.jar" 到命令行中。
·优化了性能。 此次版本关注了启动时间和后台 CPU 的使用率。一些用户报称启动应用服务器的时间比用之前版本快了 2-3 倍。
·改善了兼容性。支持所有主流的容器和框架，在其他的之上也可能工作的很好。
·扩展了对 Java 1.4 的支持。像 BEA Weblogic 8.X、Oracle OC 4J 9.x/10.X 和 Tomcat 4.x 也被支持。 阅读全文 >>
Java 2 平台企业版定义了基于组件的企业应用开发标准。不管你是否倾向于使用一种开源的 J2EE 服务器，比如 JBoss 或 Geronimo，或者你更希望得到可靠安全的商业服务支持，比如 WebSphere 和 WebLogic，你都能在那些应用服务器中使用几种不同的部署方式使用 Quartz。本章给你示范了在 J2EE 应用服务器中以不同策略部署 Quartz，你也会看到 Quartz 框架更加丰富了 J2EE。
一：假如我有 J2EE，为什么还需要 Quartz?
自从 20 世纪 90 年代末期 J2EE 首次登上舞台以来，开发人员就被某些规格决议和一些表面看来明显缺失的特征所困惑。这没必要去批判规格的制定者，更多的是说明了当有不同意见和议程的独立团体，在尝试达成统一的优先级时，就像联合国进行决议时那样，并不如所想像的那样好。许多必须的特征获得认可，但是一些关键的特征被略去留待以后加入。其中一个让早期规范遗漏的关键特征就是定时器服务。 阅读全文 >>
一：要解决的问题
我们在尝鲜 JDK1.5 的时候，相信不少人遇到过 Unsupported major.minor version 49.0 错误，当时定会茫然不知所措。因为刚开始那会儿，网上与此相关的中文资料还不多，现在好了，网上一找就知道是如何解决，大多会告诉你要使用 JDK 1.4 重新编译。那么至于为什么，那个 major.minor 究竟为何物呢？这就是本篇来讲的内容，以使未错而先知。
我觉得我是比较幸运的，因为在遇到那个错误之前已研读过《深入 Java 虚拟机》第二版，英文原书名为《Inside the Java Virtual Machine》( Second Edition)，看时已知晓 major.minor 藏匿于何处，但没有切身体会，待到与 Unsupported major.minor version 49.0 真正会面试，正好是给我验证了一个事实。 阅读全文 >>
