学习是最好的投资!
第一个问题:Spring官方建议的通知事务管理器回滚事务的方式是从事务执行上下文中抛出一个异常,当这个异常沿着堆栈抛到事务管理器中的时候,会被 catch 住,由事务管理器决定是不是需要回滚事务。
如果你使用声明式事务管理,@Transactional,默认情况下所有的 RuntimeException 会触发回滚,所有的 checked Exception 不会触发回滚。你可以通过 rollback-for 和 no-rollback-for 来调整这个配置。如果你 catch 住异常,不再抛出,异常没办法到事务管理器中,不会触发回滚操作。
@Transactional
RuntimeException
checked Exception
rollback-for
no-rollback-for
第二个问题:多个事务方法放同一个事务方法,涉及到事务的传播机制,也就是 propagation,这个选项的具体配置你可以通过官方文档了解。可以控制调用另一个配置了事务的方法时如何参与当前事务。
propagation
同时当在一个事务里面,通过 this 调用当前对象里面的其他配置了事务的方法的时候,@Transactional的配置可能是无效的。具体要看你的事务管理器是通过代理方式还是CGLIB。
this
没怎么看懂你在说什么,不是出现了异常才需要回滚么,回滚不回滚和try catch没有必然的联系,看你吧回滚方法写在哪了,事务是把几件事看做一个整体,类似于原子,不可再分,事务里的程序要么都执行完,要么都不执行,不存在哪个执行了而其他的没执行,所以事务是不需要嵌套的,这么做没意义。
1catch 住就不会滚了2建议用一个事物
catch住,如果不调用Rollback接口事务就提交了
多个事物如果整合在一起,如果你没有用Tx,会引起事务不一致的严重问题;在系统上会引起宝贵的DB链接占用问题,会导致链接池耗尽。
1.正常的一步步在栈中执行,抛出异常就是,意外终止这个执行栈,你可以把这个异常交给其他的地方去处理,但这个执行栈就终止了。2.所以执行过的语句如果需要回滚,要么在catch中去做,要么抛给其他专门的异常处理线程去处理。3.spring中的事务有专门的异常处理类吧,如果抛出异常,那么会交给它处理,它会根据你的配置进行处理4.如果在当前catch住了,那么我认为spring没那么智能吧,你只能在当前手动回滚。
第一个问题:
Spring官方建议的通知事务管理器回滚事务的方式是从事务执行上下文中抛出一个异常,当这个异常沿着堆栈抛到事务管理器中的时候,会被 catch 住,由事务管理器决定是不是需要回滚事务。
如果你使用声明式事务管理,
@Transactional
,默认情况下所有的RuntimeException
会触发回滚,所有的checked Exception
不会触发回滚。你可以通过rollback-for
和no-rollback-for
来调整这个配置。如果你 catch 住异常,不再抛出,异常没办法到事务管理器中,不会触发回滚操作。第二个问题:
多个事务方法放同一个事务方法,涉及到事务的传播机制,也就是
propagation
,这个选项的具体配置你可以通过官方文档了解。可以控制调用另一个配置了事务的方法时如何参与当前事务。同时当在一个事务里面,通过
this
调用当前对象里面的其他配置了事务的方法的时候,@Transactional
的配置可能是无效的。具体要看你的事务管理器是通过代理方式还是CGLIB。没怎么看懂你在说什么,不是出现了异常才需要回滚么,回滚不回滚和try catch没有必然的联系,看你吧回滚方法写在哪了,事务是把几件事看做一个整体,类似于原子,不可再分,事务里的程序要么都执行完,要么都不执行,不存在哪个执行了而其他的没执行,所以事务是不需要嵌套的,这么做没意义。
1catch 住就不会滚了
2建议用一个事物
catch住,如果不调用Rollback接口事务就提交了
多个事物如果整合在一起,如果你没有用Tx,会引起事务不一致的严重问题;在系统上会引起宝贵的DB链接占用问题,会导致链接池耗尽。
1.正常的一步步在栈中执行,抛出异常就是,意外终止这个执行栈,你可以把这个异常交给其他的地方去处理,但这个执行栈就终止了。
2.所以执行过的语句如果需要回滚,要么在catch中去做,要么抛给其他专门的异常处理线程去处理。
3.spring中的事务有专门的异常处理类吧,如果抛出异常,那么会交给它处理,它会根据你的配置进行处理
4.如果在当前catch住了,那么我认为spring没那么智能吧,你只能在当前手动回滚。