API 层中的所有公共写方法（包括插入、更新和删除）都应当使用事务属性 REQUIRED 加以标记。

API 层中的所有公共写方法（包括插入、更新和删除）都应当包含回滚逻辑，以标记对检查出的异常 执行回滚的事务。

API 层中的所有公共读方法默认情况下都应使用事务属性 SUPPORTS 加以标记（参见 “事务策略：了 解事务陷阱” 中的 事务策略：了解事务陷阱 侧边栏内容）。这将确保在一个事务范围的上下文内调用 读方法时，该方法被包括在事务范围内。否则，它将在事务上下文之外运行，并假设它是惟一一个在逻辑 工作单元（LUW）内得到调用的方法。我在这里假设这个读操作（作为 API 层的入口点）不会反过来对数 据库调用写操作。

API 层的事务将传播到在事务所有者 内调用的所有方法（如 下一小节 定义的那样）。

声明式事务（Declarative Transaction）模型通常用于这种模式，并假设 API 层类由一个 Java EE 容器环境管理，或由另一个框架（比如 Spring）管理。如果不是这样的话，那么很可能需要使用编程式 事务（Programmatic Transaction）模型。（参见 “Transaction strategies: Models and strategies overview” 了解更多有关这些事务模型的信息）。

根据上面列出的几条规则，如果您仔细观察的话，可能会注意到这个策略有些小问题。由于执行服务 之间的通信，一个公共 API 层更新方法可以调用另一个公共 API 层更新方法。由于这两个更新方法都是 公共方法，并且从客户机层的角度看被公开为 API 层入口点，因此它们包含了回滚逻辑。然而，如果其 中一个公共更新方法调用了另一个，那么事务所有者在某些情况下可能无法控制回滚逻辑。因此，事务所 有者在重新提交事务或采取纠正操作时，必须万分小心。遇到这些情况时，需要重新构造结构和处理逻辑 以避免发生此类问题。

限制和约束

事务策略的其中一个限制，就是客户机层（或表示层）类对任何给定事务工作单元只能发出单一的 API 层调用。这使得这种策略不太适合 “聊天” 应用程序。不幸的是，这是一种全有或全无（all-or- nothing）式的思想，并且在某些情况下需要对应用程序进行重构（本节后面将详述）。让我解释一下它 对事务策略的重要性（和必要性）。

我将对整个事务策略 系列中描述的所有事务策略应用的两条黄金法则（秘诀）是：

启动事务的方法被指定为事务所有者

只有事务所有者可以回滚事务

事务策略: API层策略-学习如何实现一个简单且健壮的事务策略(3)

如果不遵守这些法则的话，事务策略将不能正常工作。您很可能会遇到问题，导致不一致的数据和糟 糕的数据完整性。第二条法则非常重要，原因有两点。首先，如果某个方法没有启动事务，那么它就不需 要管理事务（例如，将其标记为回滚）。其次，如果调用链中较低级别的方法调用回滚事务，那么事务所 有者不能采取纠正操作来修复并重新提交事务；一旦被标记为回滚，那么这是惟一可能的结果。您无法对 事务 “撤销回滚”。

回到原点：对于 API 层事务策略，客户机绝对 不能在涉及事务的单一工作单元中对 API 层发出多个 调用。如果客户机对给定的 LUW 发出多个 API 调用，那么必须在客户机启动和终止事务工作单元。在这 种情况下，API 层方法必须拥有一个事务属性 MANDATORY，而不应包括任何回滚逻辑。记住刚才的两条黄 金法则：调用 API 层方法的客户机方法是事务所有者，只有事务所有者才负责执行回滚。

考虑图 2 所示的例子，其中一个客户机（客户机 A）向 API 层（域模型）

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