事务策略: 客户端编排策略-了解如何实现可靠的基于客户端的事务策略 - 编程入门网

我并不赞成使用细粒度的 API 层 chatty 应用程序体系结构；我认为，如果 您的应用程序是 chatty 式的，并且不能重构，则客户端编排事务策略可能是正确的选择。

策略规则和特性

以下规则和特性适用于客户端编排事务策略：

只有应用程序体系结构的客户端层和 API 层中的方法才应该包含事务逻辑。其他方法、类或组件都不 应包含事务逻辑（包括事务注释、程序化事务逻辑和回滚逻辑）。

客户端层方法是惟一负责开始、提交和回滚事务的方法。

开始事务的客户端层方法被称作事务所有者。

在大多数情况下，客户端层需要程序化的事务，这表示您必须通过编程获取事务管理程序，并编写开 始、提交和回滚逻辑。此规则的例外情况是，管理事务作用域的客户端层中的客户端业务代理由 Spring Framework 托管为 Spring bean。在这种情况下，您可以使用 Spring 提供的声明式事务模型。

由于您不能通过编程传递事务上下文，因此 API 层必须使用声明式事务模型，这表示容器将管理事务 。您只需要指定事务属性（没有回滚代码或回滚指令！）。

API 层中的所有公共写方法（插入、更新和删除）都应该标记一个 MANDATORY 事务属性，这表示需要 事务，但必须在调用方法之前建立事务上下文。与 REQUIRED 属性不同，MANDATORY 属性将不会 开始不 存在的事务，而是抛出一个异常，指示需要事务。

API 层中的所有公共写方法（插入、更新和删除）都不应该包含回滚逻辑，无论抛出的异常的类型是 什么。

API 层中的所有公共读方法默认都应该标记一个 SUPPORTS 事务属性。这将确保在作用域的上下文中 调用读方法时，它将包含在事务作用域中。否则，它将在没有事务上下文的情况下运行，这需要假设它是 在逻辑工作单元（LUW）中惟一调用的方法。我在此处假设读操作（作为 API 层的入口点）不会对数据库 调用写操作。

客户端层中的事务上下文将传播给 API 层方法以及在 API 层中调用的所有方法。

如果客户端层向 API 层发起远程调用，则客户端层必须使用支持传播事务上下文的协议和事务管理程 序（比如说 RMI-IIOP）。

局限和限制

如前所述，这种事务策略的最大一个限制就是，客户端层必须能够开始一个事务并将它传播给 API 层 。这意味着用于在客户端层和 API 层之间进行通信的协议以及客户端的类型在应用程序体系结构中发挥 着重要的作用。举例来说，您不能将此策略用于 Web 服务客户端或者 JMS 客户端，同时也不能在客户端 层和 API 层之间依赖 HTTP 通信；这两层之间中所使用的协议必须能够支持事务的传播。

与 API 层策略 不同，此策略的另一个限制是，您不能 “欺骗” 并将它增量式地引入到应用程序体 系结构中。对于 API 层事务策略，您在重构过程中在客户端层上开始一个事务并不会引起灾难性后果。 在 API 层事务策略中这样做的影响是客户端层将不能对异常采取正确的措施，并且您将不能回滚已经回 滚到 API 层中的事务。小问题很多，但并不具有毁灭性。

但是，通过客户端编排事务策略，由于 API 层使用 MANDATORY 事务属性，并且不包含事务回滚逻辑 ，因此客户端层方法必须开始一个事务。将 API 层方法修改为 REQUIRED 并添加回滚逻辑，这样会带来 “API 层策略” 中的 “局限和限制” 一节中概述的相同问题。此外，在 API 层方法中使用 REQUIRED 意味着事务可以 由 API 层开始，因此这违反了客户端编排事务策略的主要原则。

事务策略: 客户端编排策略-了解如何实现可靠的基于客户端的事务策略(3)

事务策略实现

客户端编排事务策略的实现相当简单，但由于它涉及体系结构的客户端层和 API 层，因此我将针对两 个层的方法展示事务逻辑和策略实现。

回顾 策略规则和特性 一

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