避免使用有状态性不只是对 IBM/WebSphere 的建议，这是一个基本的 Java EE 设计原则。请参见 [Jewell] 的 Tyler Jewell 对有状态 Bean 的批评，其观 点和上述的观点是相同的。

9. 使用容器管理的事务。

学习一下 Java EE 中的两阶段提交事务，并且使用这种方式，而不是开发您 自己的事务管理。容器在事务优化方面几乎总是比较好的。

使用容器管理的事务（CMT）提供了两个关键的优势（如果没有容器支持这几 乎是不可能的）：可组合的工作单元和健壮的事务行为。

如果您的应用程序代码显式地使用了开始和结束事务（也许使用 javax.jts.UserTransaction 或者甚至是本地资源事务），而将来的要求需要组 合模块（也许会是代码重构的一部分），这种情况下往往需要改变事务代码。例 如，如果模块 A 开始了一个数据库事务，更新数据库，随后提交事务，并且有模 块 B 做出同样的处理，请考虑一下当您在模块 C 中尝试使用上述两个模块，会 出现什么情况呢？现在，模块 C 正在执行一个逻辑动作，而这个动作实际上将调 用两个独立的事务。如果模块 B 在执行中失败了，而模块 A 的事务仍然能被提 交。这是我们所不希望出现的行为。如果，相反地，模块 A 和模块 B 都使用 CMT 的话，模块 C 也可以开始一个 CMT（通常通过配置描述符），并且在模块 A 和模块 B 中的事务将是同一个事务的隐含部分，这样就不再需要重写复杂的代码 了。

如果您的应用程序在同一个操作中需要访问多种资源，您就要使用两阶段提交 事务。例如，如果从 JMS 队列中删除一个消息，并且随后更新基于这条消息的纪 录，这时，要保证这两个操作都会执行或都不会执行就变得尤为重要。如果一条 消息已经从队列中被删除，而系统没有更新与此消息相关的数据库中的记录，那 么这种系统是不一致的。一些严重的客户及商业纠纷源自不一致的状态。

我们时常看到一些客户应用程序试图实现他们自己的解决方案。也许会通过应 用程序的代码在数据库更新失败的时候“撤销”对队列的操作。我们不提倡这样 做。这种实现要比您最初的想象复杂得多，并且还有许多其他的情况（想象一下 如果应用程序在执行此操作的过程中突然崩溃的情况）。作为替代的方式，应该 使用两阶段提交事务。如果您使用 CMT，并且在单一的 CMT 中访问两阶段提交的 资源（例如 JMS 和大多数数据库），WebSphere 将会处理所有的复杂工作。它将 确保整个事务被执行或者都不被执行，包括系统崩溃、数据库崩溃或其他的情况 。其实现在事务日志中保存着事务状态。当应用程序访问多种资源的时候，我们 怎么强调使用 CMT 事务的必要性都不为过。如果您所访问的资源不支持两阶段提 交，那么您当然就没有别的选择了，只能使用一种比较复杂的方法，但是您应该 尽量避免这种情况。

最重要的Java EE最佳实践(7)

10. 将 JSP 作为表示层技术的首选。

只有在需要多种表示输出类型，并且输出类型被单一的控制器及后端支持时才 使用 XML/XSLT。

我们常听到一些争论说，为什么您选择 XML/XSLT 而不是 JSP 作为表示层技 术，因为 JSP“允许您将模型和视图混合在一起”，而 XML/XSLT 不会有这种问 题。遗憾的是，这种观点并不完全正确，或者至少不像白与黑那样分的清楚。实 际上，XSL 和 XPath 是编程语言。事实上，XSL 是图灵完备的（Turing- complete），尽管它不符合大多数人定义的编程语言，因为

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!