事务策略: 高并发策略-学习如何为支持高用户并发性的应用程序实现事务策略 - 编程入门网
| 放弃了什么呢？根据您的应用程序的设计，您可能需 要在事务作用域外部执行读取操作，即使读取操作用于更新目的。“等一等！”您说：“您不能这样做 — 您可能会更新在最后一次读取之后发生了变化的数据！”这是合理的担忧，并且也是需要开始考虑折 衷的地方。通过此策略，由于您未对数据保持读取锁，因此在执行更新操作时遇到失效数据异常的机率会 增加。但是，与 Vasa 的情况一样，所有这些都可以归结为一个问题，即哪个特性更加重要：可靠、坚固 的事务策略（如 API 层策略），还是高用户并发性和吞吐量。在高并发性情形中，同时实现两者是极为 困难的。如果您尝试这样做，则可能会适得其反。
第二个折衷之处是事务可靠性的总体缺乏。此策略难以实现，并且需要更长的时间进行开发和测试， 并且比 API 层或 Client Orchestration 策略更易于出错。考虑到这些折衷，您首先应该分析当前的情 形以确定使用此策略是否是正确的方法。由于 High Concurrency 策略派生自 API 层策略，因此一种比 较好的方法是先使用 API 层策略，并使用较高的用户负载对应用程序执行负载测试（比您预期的峰值负 载更高）。如果您发现吞吐量较低、性能较第、等待次数非常多，或者甚至出现死锁，则要准备迁移到 High Concurrency 策略。 在本文的其余部分，我将向您介绍 High Concurrency 事务策略的其他一些特性，以及实现它的两种 方法。 基本结构和特性 图 1 通过我在 事务策略 系列中所使用的逻辑应用程序栈展示了 High Concurrency 事务策略。包含 事务逻辑的类显示为红色阴影。 图 1. 体系结构层和事务逻辑
事务策略: 高并发策略-学习如何为支持高用户并发性的应用程序实现事务策略(3)时间:2011-10-21 IBM Mark Richards一些 API 层策略的特性和规则是有效的 — 但并非所有。注意，图 1 中的客户机层没有事务逻辑， 这意味着任何类型的客户机都可以用于此事务策略，包括基于 Web 的客户机、桌面、Web 服务和 Java Message Service (JMS)。并且事务策略遍布于客户机下面的层中，但这不是绝对的。一些事务可能在 API 层中开始，一些在业务层中开始，还有一些甚至在 DAO 层中开始。这种一致性的缺乏是造成策略难 以实现、维护和治理的原因之一。 在大多数情况下，您会发现您需要使用 Programmatic Transaction 模型 来减小事务作用域，但有时 您仍然会使用 Declarative Transaction 模型。但是，您通常不能在相同的应用程序中混用 Programmatic 和 Declarative Transaction 模型。在使用这种事务策略时，不应该坚持使用这种 Programmatic Transaction 模型，这样您就不会遇到各种问题。但是，如果您发现自己可以在此策略中 使用 Declarative Transaction 模型，那么您应该在使用 REQUIRED 事务属性开始事务的层中标记所有 公共写方法（插入、更新和删除）。此属性表示需要一个事务，并且如果事务不存在，则由方法启动。 与其他事务策略一样，无论您选择开始事务的组件或层是什么，启动事务的方法都被认为是事务拥有 者。只要可能，事务拥有者应该是对事务执行提交和回滚的唯一方法。 事务策略实现 您可以使用两个主要技巧来实现 High Concurrency 事务策略。先读取（read-first）技巧涉及在尽 可能高的应用层（通常为 API 层）对事务作用域范围外的读取操作进行分组。低级（lower-level）技巧 涉及在体系结构中尽可能低的层启动事务，同时仍然能够更新操作的原子性和隔离。 先读取技巧 先读取技巧涉及重构（或编写）应用程序逻辑和工作流，以便所有的处理和读取操作在事务作用域的 外部首先发生。这种方法消除了不必要的共享或读取锁，但是如果数据在您能够提交工作之前更新或提交 ，则可能会引入失 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
