事务策略之API层策略.docVIP

不论您是在 EJB 2.1 或 3.0 中使用容器环境，还是使用 Spring Framework 环境，或者是 Tomcat 和 Jetty 等带有 Java Open Transaction Manager (JOTM) 的 Web 容器环境，都需要一种事务策略来确保数据库的一致性和完整性。Java Transaction API (JTA) 指定了与事务处理有关的语法和接口（参见  HYPERLINK /developerworks/cn/java/j-ts3/index.html \l resources 参考资料），但是并没有描述如何将这些构建块组合起来。正如建筑工人需要根据一张设计图来将一堆木材建造成一栋房子一样，您需要一种策略来描述如何 将事务构建块组合在一起。 关于本系列 事务可以改善数据的质量、完整性和一致性，并使您的应用程序更加健壮。在 Java 应用程序中实现成功的事务处理并非易事，它涉及到设计和编码。在这个  HYPERLINK /developerworks/cn/views/java/libraryview.jsp?search_by=%E4%BA%8B%E5%8A%A1%E7%AD%96%E7%95%A5 系列文章 中，Mark Richards 将指导您为从简单应用程序到高性能事务处理等各种用例设计有效的事务策略。 我将在本文介绍的策略名为 API Layer 事务策略。它是最健壮、最简单并且是最容易实现的事务策略。但是其简单性也带来了一些限制和一些需要考虑的因素，我将对此加以解释。我在代码示例中使用 EJB 3.0 规范；同样的概念也适用于 Spring Framework 和 JOTM。 基本结构 API Layer 事务策略的命名基于这样一个事实：所有事务逻辑包含在逻辑应用程序架构的 API 层。这个层是一个逻辑层 — 有时也被称为应用程序的域层（domain layer）或 facade 层，它以公共方法或接口的形式向客户机（或表示层）公开功能。之所以说是逻辑 层，是因为可以从本地访问域层（通过直接实例化和调用），或通过 HTTP、远程方法调用（RMI）、通过 EJB 使用 RMI over Internet Inter-Orb Protocol (RMI-IIOP)，甚至通过 Java Message Service (JMS) 进行远程访问。 图 1 展示了大多数 Java 应用程序的典型逻辑应用程序层堆栈： 图 1. 架构层和事务逻辑 图 1 中的架构实现了 API Layer 事务策略。包含事务逻辑的类使用红色背景表示。注意，这些只包含应用程序架构的域类（API 层）。客户机层、业务层和表示层没有包含事务逻辑，意味着这些层并不能开始、提交??回滚事务，也不会包含事务注释，比如 EJB 3.0 中的 @TransactionAttribute 注释。整个应用程序架构中用于启动、提交和回滚事务的惟一方法就是 API 层的域类中包含的公共方法。这就解释了为什么 API 层是最健壮、最简单的事务策略。 不要局限在图 1 所示的 4 个层上。应用程序架构可以包含更多的层，也可能包含比这更少的层。可以将表示层和域层结合放到单个 WAR 文件中，或将域类单独放到一个 EAR 文件中。您可能将域类中包含的业务逻辑作为一个层，而不是两个。这都不会影响事务策略的工作方式或实现方式。 这个事务策略非常适合拥有粗粒度 API 层的应用程序。并且由于表示层并未包含任何事务逻辑（甚至更新请求），因此此策略非常适合那些必须支持多客户机通道的应用程序，包括 Web 服务客户机、桌面客户机和远程客户机。但是这种灵活性需要付出一定代价 — 即客户机层仅限于对给定事务工作单元的单一请求。我将在本文后面解释这一限制的必要性。 策略设置和特征 以下规则和特征将应用到 API Layer 事务策略： 只有包含在应用程序架构的 API 层中的公共方法包含事务逻辑。其他方法、类或组件都不应包含事务逻辑（包括事务注释、编程式事务逻辑和回滚逻辑）。 API 层中的所有公共写方法（包括插入、更新和删除）都应当使用事务属性 REQUIRED 加以标记。 API 层中的所有公共写方法（包括插入、更新和删除）都应当包含回滚逻辑，以标记对检查出的异常执行回滚的事务。 API 层中的所有公共读方法默认情况下都应使用事务属性 SUPPORTS 加以标记（参见 “ HYPERLINK /developerworks/cn/java/j-ts1.html 事务策略：了解事务陷阱” 中的  HYPERLINK /developerworks/cn/java/j-ts1.html 事务策略：了解事务陷阱 侧边栏内容）