阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 blog.csdn.net/Yang_yangyang/article/details/114359881 「null」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

用 Spring 的 @Transactional 注解控制事务有哪些不生效的场景？

不知道小伙伴们有没有这样的经历，在自己开心的编写业务代码时候，突然某一个方法里的事务好像失效了。然后 debug 跟踪代码时发现，自己第一步的 insert 或者 update 的数据在语句执行完毕后，数据库中并没有立即出现更改或保存完的新数据。

所以一度怀疑spring 的事务失效了。那么这篇文章就来总结一下，大家给大家造成 “spring事务失效”错觉的几个常见场景，然后对症下药。

Let's GO!!!

以本人的经历中遇到的问题，大概分有以下几个场景：

数据库引擎是否支持事务（Mysql 的 MyIsam引擎不支持事务）；
注解所在的类是否被加载为 Bean（是否被spring 管理）；
注解所在的方法是否为 public 修饰的；
是否存在自身调用的问题；
所用数据源是否加载了事务管理器；
@Transactional的扩展配置propagation是否正确。

下面展开分析每一个场景：

数据库引擎不支持事务

这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。

根据 MySQL 的官方文档：

https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html

从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是白搭。

没有被 Spring 管理

如下面例子所示：

// @Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        // update order
    }

}

如果此时把 @Service 注解注释掉，这个类就不会被加载成一个 Bean，那这个类就不会被 Spring 管理了，事务自然就失效了。

方法不是 public 的

以下来自 Spring 官方文档：

When using proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do annotate protected, private or package-visible methods with the @Transactional annotation, no error is raised, but the annotated method does not exhibit the configured transactional settings. Consider the use of AspectJ (see below) if you need to annotate non-public methods.

大概意思就是 @Transactional 只能用于 public 的方法上，否则事务不会失效，如果要用在非 public 方法上，可以开启 AspectJ 代理模式。

自身调用问题

来看两个示例：

//示例1

@Service
public class OrderServiceImpl implements OrderService {

    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional
    public void updateOrder(Order order) {
        // update order
    }

}
//示例2

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateOrder(Order order) {
        // update order
    }

}

示例1 中，update方法上面没有加 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？
示例2 中，update方法上面没有加 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？

这两个例子的答案是：都不管用！

因为它们发生了自身调用，就调该类自己的方法，而没有经过 Spring 的代理类，默认只有在外部调用事务才会生效，这也是老生常谈的经典问题了。

这个的解决方案之一就是在的类中注入自己，用注入的对象再调用另外一个方法，这个不太优雅。

数据源没有配置事务管理器

如下代码所示，当前数据源若没有配置事务管理器，那也是白搭！

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

@Transactional的扩展配置不支持事务

Propagation.NOT_SUPPORTED：表示不以事务运行，当前若存在事务则挂起。这表示不支持以事务的方式运行，所以即使事务生效也是白搭！

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    public void updateOrder(Order order) {
        // update order
    }

}

异常被吃了

这个也是出现比较多的场景：把异常吃了，然后又不抛出来，事务也不会回滚！

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        try {
            // update order
        } catch {

        }
    }

}

异常类型错误

接上面的例子，再抛出一个异常

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        try {
            // update order
        } catch {
            throw new Exception("更新错误");
        }
    }

}

这样事务也是不生效的，因为默认回滚的是：RuntimeException，如果你想触发其他异常的回滚，需要在注解上配置一下，如：

@Transactional(rollbackFor = Exception.class)

这个配置仅限于 Throwable 异常类及其子类。

总结

本文总结了 8 种事务失效的场景，其实发生最多就是自身调用、异常被吃、异常抛出类型不对这 3 个了，像文章开头说的那样，本文不一定总结得全，只是总结常见的事务失效的场景，如果你还知道其他场景也欢迎留言分享。

芋道源码 —— 纯源码解析博客

Spring 事务失效的 8 大场景，看看你都遇到过几个？

Let's GO!!!

下面展开分析每一个场景：

总结