spring中事务注解@Transactional与trycatch的使⽤
spring事务注解@Transactional与trycatch
在项⽬中 @service层中我们会经常在做⼀些增删改操作的⽅法上看到 spring 的事务注解 @transaction 已知@transaction 是让spring 帮我们实现事务的控制。
但是在项⽬中会经常看到有的⽅法中会存在trycatch块包括的⽅法上注解着@transaction
eg：
@Override
@Transactional
public Json addOrder(TOrderAddReq tOrderAddReq) {
try{
//增删改⽅法
} catch (Exception e) {
.....
e.printStackTrace();}
//        }
return json;
}
上述的⽅法执⾏后可以看到事务并没有执⾏，接下来再看⼀个例⼦eg：
spring roll怎么读@Override
@Transactional
public Json addOrder(TOrderAddReq tOrderAddReq) {
try{
//增删改⽅法
} catch (Exception e) {
// ⼿动硬编码开启spring事务管理
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
e.printStackTrace();}
//        }
return json;
}
上述⽅法执⾏后我们可以看到事务最后执⾏了，但实际上事务执⾏只是因为⼿动硬编码开启spring事务管理起了作⽤⽽⽅法上的注解并没有起作⽤
接下来再看⼀个例⼦eg
@Override
@Transactional
public Json addOrder(TOrderAddReq tOrderAddReq) {
try{
//增删改⽅法
} catch (Exception e) {
throw new RuntimeException();
}
//        }
return json;
}
上述⽅法执⾏后我们可以看到事务是执⾏了的，但这⾥有个⼩细节:@Transactional不做任何配置默认是对抛出的unchecked 异常回滚，checked异常不会回滚，为了让所有异常都会让事务启动可以将 @Transactional配置为
@Transactional(rollbackFor = Exception.class)
解释：
spring的事务边界是在调⽤业务⽅法之前开始的，业务⽅法执⾏完毕之后来执⾏commit or rollback(spring默认取决于是否抛出runtime异常).
如果抛出runtime exception 并在你的业务⽅法中没有catch到的话，事务会回滚。
⼀般不需要在业务⽅法中catch异常，如果⾮要catch，在做完你想做的⼯作后（⽐如关闭⽂件等）⼀定要抛出runtime exception，否则spring会将你的操作commit，这样就会产⽣脏数据.所以你的catch代码是画蛇添⾜。
@Transactional回滚问题（try catch、嵌套）
Spring 事务注解 @Transactional 本来可以保证原⼦性，如果事务内有报错的话，整个事务可以保证回滚，但是加上try catch 或者事务嵌套，可能会导致事务回滚失败。测试⼀波。
准备
建两张表，模拟两个数据操作
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
`age` smallint(3) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
CREATE TABLE `role` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`role_name` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
测试
根据排列组合原理，我们进⾏四种测试：1、⽆try catch、⽆嵌套；2、有try catch、⽆嵌套；3、⽆try catch、有嵌套；4、都有。
最简单测试
如果我们单纯@Transactional，事务可以正常回滚吗？
@GetMapping("/saveNormal0")
@Transactional
public void saveNormal0() throws Exception {
int age = Int(100);
User user = new User().setAge(age).setName("name:"+age);
userService.save(user);
throw new RuntimeException();
}
如果事务内报了RuntimeException错误，事务可以回滚。
@GetMapping("/saveNormal0")
@Transactional
public void saveNormal0() throws Exception {
int age = Int(100);
User user = new User().setAge(age).setName("name:"+age);
userService.save(user);
throw new Exception();
}
如果事务内报了Exception错误（⾮RuntimeException错误），事务不可以回滚。
@GetMapping("/saveNormal0")
@Transactional( rollbackFor = Exception.class)
public void saveNormal0() throws Exception {
int age = Int(100);
User user = new User().setAge(age).setName("name:"+age);
userService.save(user);
throw new Exception();
}
如果是Exception错误（⾮RuntimeException），加上 rollbackFor = Exception.class 参数也可以实现回滚。
结论⼀：对于@Transactional可以保证RuntimeException错误的回滚，如果想保证⾮RuntimeException错误的回滚，需要加上rollbackFor = Exception.class 参数。
try catch 影响
经过博主多种情况测试，发现try catch对回滚这个事本⾝没有什么影响，结论⼀照样成⽴。try catch只是对异常是否可以被@Transactional 感知到有影响。如果错误抛到切⾯可以感知到的地步，那就可以起作⽤。
@GetMapping("/saveTryCatch")
@Transactional( rollbackFor = Exception.class)
public void saveTryCatch() throws Exception{
try{
int age = Int(100);
User user = new User().setAge(age).setName("name:"+age);
userService.save(user);
throw new Exception();
}catch (Exception e){
throw e;
}
}
⽐如上⾯⼀段代码就回滚了。
@GetMapping("/saveTryCatch")
@Transactional( rollbackFor = Exception.class)
public void saveTryCatch() throws Exception{
try{
int age = Int(100);
User user = new User().setAge(age).setName("name:"+age);
userService.save(user);
throw new Exception();
}catch (Exception e){
}
}
然⽽，将catch中的错误不继续⽹上抛，切⾯⽆法感知到错误，⽆法进⾏处理，那么事务就⽆法回滚了。
结论⼆：try catch只是对异常是否可以被@Transactional 感知到有影响。如果错误抛到切⾯可以感知到的地步，那就可以起作⽤。
事务嵌套影响
⾸先经过实验，结论⼀仍然成⽴，即，当不加上rollbackFor = Exception.class 的时候，⽆论内外报RuntimeException，都会回滚；⽆论内外报⾮RuntimeException 错误，都不会回滚。如果加上rollbackFor = Exception.class，⽆论内外怎么报错，都会回滚。这些代码就不给出了。接下来，试下下⾯两种情况：
@GetMapping("/out")
@Transactional( rollbackFor = Exception.class)
public void out() throws Exception{
innerService.inner();
int age = Int(100);
User user = new User().setAge(age).setName("name:" + age);
userService.save(user);
throw new Exception();
}
@Transactional
public void inner() throws Exception{
Role role = new Role();
role.setRoleName("roleName:"+new Random().nextInt(100));
roleService.save(role);
//        throw new Exception();
}
情况⼀，外⾯事务加上rollbackFor = Exception.class，⾥⾯事务不加，测试内外分别报错的情况（为了简化代码量，只给出了外⾯报错的代码），都可以回滚。因为，⽆论如何，错误都抛给了外⾯那个事务进⾏处理，⽽外⾯那个加上了rollbackFor = Exception.class，具备处理⾮RuntimeException错误的能⼒，所以都可以让事务进⾏正常回滚。
下⾯看情况⼆，⾥⾯的事务加上rollbackFor = Exception.class，外⾯不加，外⾯报错。
@GetMapping("/out")
@Transactional
public void out() throws Exception{
innerService.inner();
int age = Int(100);
User user = new User().setAge(age).setName("name:" + age);
userService.save(user);
throw new Exception();
}
@Transactional( rollbackFor = Exception.class)
public void inner() throws Exception{
Role role = new Role();
role.setRoleName("roleName:"+new Random().nextInt(100));
roleService.save(role);
}
事务都⽆法回滚，这是我们有个疑问，⾥⾯的事务明明有很强的处理能⼒啊，为什么和外⾯⼀起回滚失败呢，别着急，等等聊这个。
然后试下⾥⾯报错：
@GetMapping("/out")
@Transactional
public void out() throws Exception{
innerService.inner();
int age = Int(100);
User user = new User().setAge(age).setName("name:" + age);
userService.save(user);
}
@Transactional( rollbackFor = Exception.class)
public void inner() throws Exception{
Role role = new Role();
role.setRoleName("roleName:"+new Random().nextInt(100));
roleService.save(role);
throw new Exception();
}
咦，这回都进⾏了正常的回滚。我的天，这回外⾯没有处理能⼒，为什么接受⾥⾯抛出来的错误，也进⾏了回滚看上去，就好像⾥外事务总是同⽣共死的对不对？原来，@Transactional还有个参数，看下源码，这个注解还有默认值：
Propagation propagation() default Propagation.REQUIRED;
REQUIRED的意思是说，事务嵌套的时候，如果发现已经有事务存在了，就加⼊这个事务，⽽不是新建⼀个事务，所以根本就不存在两个事务，⼀直只有⼀个！⾄于，此参数其他值，本⽂不进⾏测试。回到上⾯的问题，当外⾯报错的时候，此时查看事务，没有增加rollbackFor = Exception.class参数，即没有处理⾮RuntimeException能⼒，所以代码⾛完，貌似“两个事务”，都回滚失败了。当⾥⾯报错的时候，事务已经添加上了处理⾮RuntimeException能⼒，所以，代码⾛完就回滚成功了。
结论三：由于REQUIRED属性，“两个事务”其实是⼀个事务，处理能⼒看报错时刻，是否添加了处理⾮RuntimeException的能⼒。
try catch和事务嵌套共同影响
在结论⼀⼆三成⽴的条件下，探索共同影响的问题就简单多了，由于情况太多，就不进⾏过多的代码展⽰了。
结论
结论⼀：
对于@Transactional可以保证RuntimeException错误的回滚，如果想保证⾮RuntimeException错误的回滚，需要加上rollbackFor = Exception.class 参数。
结论⼆：
try catch只是对异常是否可以被@Transactional 感知到有影响。如果错误抛到切⾯可以感知到的地步，那就可以起作⽤。
结论三：
由于REQUIRED属性，“两个事务”其实是⼀个事务，处理能⼒看报错时刻，是否添加了处理⾮RuntimeException的能⼒。
以上为个⼈经验，希望能给⼤家⼀个参考，也希望⼤家多多⽀持。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。