图 2. 使用 MANDATORY 属性

在这种情况下，客户机启动事务；因此使用 REQUIRED 事务属性。注意客户机还负责执行回滚，遵守 刚才提到的两条黄金法则。域类属性有一个事务属性 MANDATORY，因为客户机正在启动事务，而域模型（ insertTrade()）不负责执行回滚。

该策略适合图 2 所示的场景。然而，假设您有另一个客户机应用程序（客户机 B）需要使用同一个域 模型（insertTrade()），如图 3 所示：

图 3. 非事务性客户机问题

注意，客户机 B 并没有启动事务（它可以是一个远程 HTTP 客户机、消息传递客户机、或其他无法使 用事务的 Java 应用程序）。由于域模型方法被标记为 MANDATORY，客户机 B 将得到一个 TransactionRequiredException，表示事务需要调用该方法。

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

如果没有提供合适的事务策略，那么通常解决此问题的办法就是将域模型（insertTrade()）中的事务 属性修改为 REQUIRED。现在，如果返回到客户机 A 的调用，将注意到您并没有影响到任何内容；客户机 A 启动了一个事务，然后将事务上下文传递给域模型方法。由于域模型方法现在被标记为 REQUIRED，因 此它将使用现有的事务上下文。注意，域模型方法并没有包含回滚逻辑。执行了域模型后（不管是否出现 异常），控制权将返回给客户机。这些操作都可以在客户机 A 中正确地执行。然而，如果观察一下客户 机 B，则出现了一个问题：由于没有提供任何事物上下文，域模型方法（insertTrade()）启动了一个新 事务，但是在出现被检测到的异常后，由于域模型方法不负责执行回滚，因此没有执行任何回滚。图 4 解释了这一错误条件：

图 4. 使用 REQUIRED 属性而未执行回滚

在为提供合适事务策略的情况下，解决这一问题的惯用方法是向域模型方法添加回滚逻辑，以满足来 自客户机 B 的调用。然而，如图 5 所示，这将在客户机 A 中引发问题：

图 5. 客户机回滚问题

客户机 A 在尝试回滚事务时，不仅会收到一个异常，而且客户机 A 还不能采取纠正操作，因为事务 已经被标记为回滚。

如此反复……

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

这解释了事务策略为什么如此重要，以及为什么它们必须是绝对的。如前所述，您会发现对于 LUW 请 求，应用程序使用 85% 的单 API 层调用和 15% 的多 API 层调用。如果是这样的话（或类似的情形）， 那么有两种选择：不要协调事务工作单元中的多个调用（这不是个好主意），或者（更好的方法）是使用 一个聚合 API 层方法将多个 API 调用重构为一个单一的 API 调用。

为了解释这种重构技巧，我假设您拥有两个 API 层方法 insertTrade() 和 updateAcct()，如清单 1 所示：

清单 1. 多个 API 层方法

@Stateless
@Remote(TradingService.class)
public　class　TradingServiceImpl　implements　TradingService　{
　　@PersistenceContext(unitName="trading")　EntityManager　em;　
　　@Resource　SessionContext　ctx;
　　@TransactionAttribute(TransactionAttributeType.REQUIRED)
　　public　long　insertTrade(TradeData　trade)　throws　Exception　{　
　　　try　{
　　　　　em.persist(trade);　
　　　　　return　trade.getTradeId();　
　　　}　catch　(Exception　up)　{
　　　　　ctx.setRollbackOnly();
　　　　　throw　up;
　　　}
　　}
　　@TransactionAttribute(TransactionAttributeType.REQUIRED)
　　public　void　updateAcct(TradeData　trade)

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