阿里巴巴Java规范:方法【edit】须要在Transactional注解指定rollbackFor或者在方法中显示的rollback。数据库
先来看看异常的分类架构
error是必定会回滚的框架
这里Exception是异常,他又分为运行时异常RuntimeException和非运行时异常.net
若是不对运行时异常进行处理,那么出现运行时异常以后,要么是线程停止,要么是主程序终止。 若是不想终止,则必须捕获全部的运行时异常,决不让这个处理线程退出。线程
队列里面出现异常数据了,正常的处理应该是把异常数据舍弃,而后记录日志。不该该因为异常数据而影响下面对正常数据的处理。代理
非运行时异常是RuntimeException之外的异常,类型上都属于Exception类及其子类。如IOException、SQLException等以及用户自定义的Exception异常。扩展:Java项目构建基础:统一结果,统一异常,统一日志日志
对于这种异常,JAVA编译器强制要求咱们必须对出现的这些异常进行catch并处理,不然程序就不能编译经过。因此,面对这种异常无论咱们是否愿意,只能本身去写一大堆catch块去处理可能的异常。对象
开始主题,@Transactional若是只这样写,blog
Spring框架的事务基础架构代码将默认地 只 在抛出运行时和unchecked exceptions时才标识事务回滚。继承
也就是说,当抛出个RuntimeException 或其子类例的实例时。(Errors 也同样 - 默认的 - 标识事务回滚。)从事务方法中抛出的Checked exceptions将 不 被标识进行事务回滚。
注意: 若是异常被try{}catch{}了,事务就不回滚了,若是想让事务回滚必须再往外抛try{}catch{throw Exception}。
Spring团队的建议是你在具体的类(或类的方法)上使用 @Transactional 注解,而不要使用在类所要实现的任何接口上。
你固然能够在接口上使用 @Transactional 注解,可是这将只能当你设置了基于接口的代理时它才生效。
由于注解是不能继承的,这就意味着若是你正在使用基于类的代理时,那么事务的设置将不能被基于类的代理所识别,并且对象也将不会被事务代理所包装(将被确认为严重的)。所以,请接受Spring团队的建议而且在具体的类上使用 @Transactional 注解。
@Transactional 注解标识的方法,处理过程尽可能的简单。尤为是带锁的事务方法,能不放在事务里面的最好不要放在事务里面。能够将常规的数据库查询操做放在事务前面进行,而事务内进行增、删、改、加锁查询等操做。
注:rollbackFor 能够指定可以触发事务回滚的异常类型。Spring默认抛出了未检查unchecked异常(继承自 RuntimeException 的异常)或者 Error才回滚事务;其余异常不会触发回滚事务。
若是在事务中抛出其余类型的异常,但却指望 Spring 可以回滚事务,就须要指定 rollbackFor属性。
做者:Mint6
blog.csdn.net/Mint6/article/details/78363761