将相关的操作归在一起

由于每个事务都有不小的开销，您可能认为最好是在单个事务中执行尽可能多的操作以使每个操作的开销达到最小。但规则 1 告诉我们长事务对可伸缩性不利。那么如何实现最小化每个操作的开销和可伸缩性之间的平衡呢？

我们把规则 1 设置为逻辑上的极端 ― 每个事务一个操作 ― 这样不仅会导致额外开销，还会危及应用程序状态的一致性。假定事务性资源管理器维护应用程序状态的一致性（请回忆一下第 1 部分，其中“ACID”的“C”代表“一致性”（Consistency）），但它们依赖应用程序来定义一致性的意思。实际上，我们在描述事务时使用的一致性的定义有点圆滑：应用程序说一致性是什么意思它就是什么意思。应用程序把几组应用程序状态的变化组织到几个事务中，结果应用程序的状态就成了 定义上的（by definition）一致。然后资源管理器确保如果它必须从故障恢复的话，就把应用程序状态恢复到最近的一致状态。

在第 1 部分中，我们给出了一个在银行应用程序中将资金从一个帐户转移到另一个帐户的示例。清单 1 展示了这个示例可能的 SQL 实现，它包含 5 个 SQL 操作（一个选择，两个更新和两个插入操作）：

Java理论和实践: 理解JTS ― 平衡安全性和性能(2)

清单 1. 资金转移的样本 SQL 代码

SELECT accountBalance INTO aBalance 　　FROM Accounts WHERE accountId=aId; IF (aBalance >= transferAmount) THEN 　　UPDATE Accounts 　　　　SET accountBalance = accountBalance - transferAmount 　　　　WHERE accountId = aId; 　　UPDATE Accounts 　　　　SET accountBalance = accountBalance + transferAmount 　　　　WHERE accountId = bId; 　　INSERT INTO AccountJournal (accountId, amount) 　　　　VALUES (aId, -transferAmount); 　　INSERT INTO AccountJournal (accountId, amount) 　　　　VALUES (bId, transferAmount); ELSE 　　FAIL "Insufficient funds in account"; END IF

如果我们把这个操作作为五个单独的事务来执行会发生什么情况？这样不仅会使执行速度变慢（由于事务开销），还会失去一致性。例如，如果一个人从帐户 A 取了钱，作为执行第一次 SELECT（检查余额）和随后的记入借方 UPDATE 之间的一个单独事务的一部分，会发生什么情况？这样会违反我们认为这段代码会强制遵守的业务规则 ― 帐户余额应该是非负的。如果在第一次 UPDATE 和第二次 UPDATE 之间系统失败会发生什么情况？现在，当系统恢复时，钱已经离开了帐户 A 但还没有记入帐户 B 的贷方，并且也无记录说明原因。这样，哪个帐户的所有者都不会开心。

清单 1 中的五个 SQL 操作是单个相关操作 ― 将资金从一个帐户转移到另一个帐户 ― 的一部分。因此，我们希望要么全部执行它们，要么一个也不执行，建议在单个事务中全部执行它们。

规则 3：将相关操作归到单个事务中。

理想化的平衡

规则 1 说事务应尽可能短小。清单 1 中的示例表明有时候我们必须把一些操作归到一个事务中来维护一致性。当然，它要依赖应用程序来确定“相关操作”是由什么组成的。我们可以把规则 1 和 3 结合在一起，提供一个描述事务范围的一般指导，我们规定它为规则 4：

规则 4：把相关操作归到单个事务中，但把不相关的操作放到单独的事务中。

容器管理的事务

在使用容器管理的事务时，不是显式声明事务的起点和终点，而是为每个 EJB 方法定义事务性需求。bean 的 assembly-descriptor 的 container-transaction 部分的 trans-attribute 元素中定义了事务模式。（清单 2 中显示了一个 assembly-descriptor 示例。）方法的事务模式以及

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