3 回答
TA贡献1820条经验 获得超10个赞
就您的示例而言,如果inner()有:
@Transactional(propagation=Propagation.REQUIRES_NEW)
public void inner(){
//some logic
}
然后,如果它在outer()循环中的第二个调用中抛出异常,则第一个调用中的更改将已经提交 - 由其REQUIRES_NEW.
如果inner()有:
@Transactional(propagation=Propagation.NESTED)
public void inner(){
//some logic
}
然后将回滚第一次调用的更改 - 因为outer().
传播级别inner()真正开始重要的一点是outer()循环是否要处理以下异常inner():
@Transactional
public void outer() {
for (int i = 0; i < 100500; i++) {
try {
inner();
} catch (Exception ex) {
// Report and continue
}
}
// Something else that could fail
}
显然,两者REQUIRES_NEW并NESTED只保留从成功改变inner()通话。但关键的区别在于,NESTED如果outer().
正如您所说,另一个因素是可扩展性 - 某些数据库可能不会通过NESTED传播来理解父事务的大小。
此外,这可能值得一提——尽管我怀疑它只是为了让示例更加清晰。this.inner()直接调用是绕过 Spring 事务顾问程序。它需要被允许注入一个“被建议的 bean”,以允许@Transactional注释在调用之前和之后发挥它的魔力——例如nextAutowiredBean.inner()。
TA贡献1876条经验 获得超7个赞
我看到的最大差异:
在嵌套的情况下:
如果外部事务回滚,则嵌套的 tra 也会回滚。
可见性:如果数据库同时执行非常常见的 MVCC,
嵌套的 tra 会看到外部 tra 的先前更改。
在外部提交后,嵌套 tra 的更改将被提交,并且对其他 tra 可见。
性能:请注意,外部事务的工作集会被内部事务扩展。所以更多的锁,更多的 MVCC 原像存储,更长的重做日志条目。
在 requires_new 的情况下:
如果外层事务回滚,则外层tra回滚的情况下,内层tra的变化不会回滚。
可见性:对于同时非常常见的 MVCC,
内部 tra 不会看到尚未提交的外部 tra 所做的更改。
在这个内部 tra 提交之后,甚至在外部 tra 提交之前,嵌套 tra 的更改将被提交并立即对其他 tra 可见。锁更少,但由于提交更多的外部操作,redo-lock 中的记录更多。
在性能方面,如果其他因素不重要,您可以在交易大小和交易数量之间找到收支平衡。如果嵌套的速度比 requires_new 快,那么这个问题没有通用的答案。
TA贡献1853条经验 获得超6个赞
如果您的内部逻辑独立于外部逻辑,则使用 Requires_new,如果不使用嵌套。
例如,您的外部方法可能正在处理包含大量记录的作业并调用保持作业状态(进度、警告和验证错误)的内部方法。您希望内部方法事务是独立的,并且它的数据库更改会立即保存,以便系统的其他部分可以显示进度。如果外部方法遇到异常,它的事务会回滚,但内部方法的事务不会。
当您需要将外部和内部更改同时保留或同时回滚时,您可能希望使用嵌套或依赖事务。例如,您需要创建一个新用户(使用“外部”服务)并保存他们的地址(使用“内部”服务)。如果您的要求是用户必须有一个地址,那么如果保存用户或地址失败,您希望这两个更改都回滚。
添加回答
举报