简介：对于维护数据的一致性和完整性而言，有效并且健壮的事务策略至关重要。API Layer 事务策 略易于实现，并且非常适合用于大部分业务应用程序。 事务策略 系列文章的作者 Mark Richards 借助 Enterprise JavaBeans (EJB) 3.0 规范的示例，解释了事务策略的含义，以及如何在 Java 平台 上实现它。
不论您是在 EJB 2.1 或 3.0 中使用容器环境，还是使用 Spring Framework 环境， 或者是 Tomcat 和 Jetty 等带有 Java Open Transaction Manager (JOTM) 的 Web 容器环境，都需要一 种事务策略来确保数据库的一致性和完整性。Java Transaction API (JTA) 指定了与事务处理有关的语 法和接口，但是并没有描述如何将这些构建块组合起来。正如建筑工人需要根据一张设计图来将一堆木材 建造成一栋房子一样，您需要一种策略来描述如何 将事务构建块组合在一起。
关于本系列
事务可以改善数据的质量、完整性和一致性，并使您的应用程序更加健壮。在 Java 应用程序中实现 成功的事务处理并非易事，它涉及到设计和编码。在这个 系列文章 中，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 服务客户机、桌面 客户机和远程客户机。但是这种灵活性需要付出一定代价 — 即客户机层仅限于对给定事务工作单元的单 一请求。我将在本文后面解释这一限制的必要性。