REQUIRES_NEW 事务属性陷阱
不管是使用 Spring Framework，还是使用 EJB，使用 REQUIRES_NEW 事务属性都会得到不好的结果并导致数据损坏和不一致。REQUIRES_NEW 事务属性总是会在启动方法时启动一个新的事务。许多开发人员都错误地使用 REQUIRES_NEW 属性，认为它是确保事务启动的正确方法。考虑清单 11 中的两个方法：
清单 11. 使用 REQUIRES_NEW 事务属性
| 1 2 3 4 5 | @Transactional(propagation=Propagation.REQUIRES_NEW)
public long insertTrade(TradeData trade) throws Exception {...}
@Transactional(propagation=Propagation.REQUIRES_NEW)
public void updateAcct(TradeData trade) throws Exception {...}
|
注意，清单 11 中的两个方法都是公共方法，这意味着它们可以单独调用。当使用 REQUIRES_NEW 属性的几个方法通过服务间通信或编排在同一逻辑工作单元内调用时，该属性就会出现问题。例如，假设在清单 11 中，您可以独立于一些用例中的任何其他方法来调用 updateAcct() 方法，但也有在 insertTrade() 方法中调用 updateAcct() 方法的情况。现在如果调用 updateAcct() 方法后抛出异常，交易订单就会回滚，但帐户更新将会提交给数据库，如清单 12 所示：
清单 12. 使用 REQUIRES_NEW 事务属性的多次更新
| 1 2 3 4 5 6 7 | @Transactional(propagation=Propagation.REQUIRES_NEW)
public long insertTrade(TradeData trade) throws Exception {
em.persist(trade);
updateAcct(trade);
//exception occurs here! Trade rolled back but account update is not!
...
}
|
之所以会发生这种情况是因为 updateAcct() 方法中启动了一个新事务，所以在 updateAcct() 方法结束后，事务将被提交。使用 REQUIRES_NEW 事务属性时，如果存在现有事务上下文，当前的事务会被挂起并启动一个新事务。方法结束后，新的事务被提交，原来的事务继续执行。
由于这种行为，只有在被调用方法中的数据库操作需要保存到数据库中，而不管覆盖事务的结果如何时，才应该使用 REQUIRES_NEW 事务属性。比如，假设尝试的所有股票交易都必须被记录在一个审计数据库中。出于验证错误、资金不足或其他原因，不管交易是否失败，这条信息都需要被持久化。如果没有对审计方法使用 REQUIRES_NEW 属性，审计记录就会连同尝试执行的交易一起回滚。使用 REQUIRES_NEW属性可以确保不管初始事务的结果如何，审计数据都会被保存。这里要注意的一点是，要始终使用 MANDATORY 或 REQUIRED 属性，而不是 REQUIRES_NEW，除非您有足够的理由来使用它，类似审计示例中的那些理由。
该文章为转载 附上原文地址：https://www.ibm.com/developerworks/cn/java/j-ts1.html | 
转播
