阅读全文

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

摘要: 原创出处程序猿DD 「翟永超」欢迎转载，保留摘要，谢谢！

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

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

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

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

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

认真的源码交流微信群。

@Transactional是我们在用Spring时候几乎逃不掉的一个注解，该注解主要用来声明事务。它的实现原理是通过Spring AOP在注解修饰方法的前后织入事务管理的实现语句，所以开发者只需要通过一个注解就能代替一系列繁琐的事务开始、事务关闭等重复性的编码任务。

编码方式确实简单了，但也因为隐藏了直观的实现逻辑，一些错误的编码方法可能会让@Transactional注解失效，达不到事务的作用。最直接的表现就是：方法执行过程中抛出了异常，但事务没有回滚，最终导致了脏数据的产生。

之前我在博客上也写过一篇有趣的讨论我来出个题：这个事务会不会回滚？，当时很多人都给出了标准的错误答案，如果没看过的小伙伴不妨进去挑战一下？

虽然之前讨论了一些特殊情况，但还是一直有小伙伴会邮件、微信群里问一些关于事务失效的问题。主要还是@Transactional声明事务失效的情况真的是多种多样！所以，今天写一篇总结一下，如果下次再碰到，那就打开这片文章，一个个顺下来看，是不是哪里写错了。当然可能这里还会有遗漏，所以如果你有其他错误案例，也可以告诉我，我会持续整理到这篇文章里。

1. 在同一个类中调用

错误案例：

public class A {
    
    public void methodA() {
        methodB();
        
        // 其他操作
    }

    @Transactional
    public void methodB() {
        // 写数据库操作
    }
    
}

这类错误适用于所有基于Spring AOP实现的注解。

解决这个问题的方法比较简单，还是合理规划好层次关系即可，比如这样：

@Service
@AllArgsConstructor
public class A {
    
    private B b;
    
    public void methodA() {
        b.methodB();
        // 其他操作
    }
}

@Service
public class B {

    @Transactional
    public void methodB() {
        // 写数据库操作
    }
    
}

注意：这里A类用了构造器注入B的实现，构造函数用Lombok的@AllArgsConstructor生成。

2. @Transactional修饰方法不是public

错误案例：

public class TransactionalMistake {
    
    @Transactional
    private void method() {
        // 写数据库操作
    }
    
}

这也是基于Spring AOP实现的注解所要满足的要求。这个最简单，很好理解，也很直观，就不详细展开了。直接把方法访问类型改成public即可。

3. 不同的数据源

错误案例：

public class TransactionalMistake {

    @Transactional
    public void createOrder(Order order) {
        orderRepo1.save(order);
        orderRepo2.save(order);
    }

}

有的时候，我们一个操作可能会同时写多个数据源，比如上面这个例子里的orderRepo1和orderRepo2是连接的两个不同数据源。默认情况下，这种跨数据源的事务是不会成功的。

如果要在多个数据源之间实现事务，那么可以引入JTA。

4. 回滚异常配置不正确

默认情况下，仅对RuntimeException和Error进行回滚。如果不是的它们及它们的子孙异常的话，就不会回滚。

所以，在自定义异常的时候，要做好适当的规划，如果要影响事务回滚，可以定义为RuntimeException的子类；如果不是RuntimeException，但也希望触发回滚，那么可以使用rollbackFor属性来指定要回滚的异常。

public class TransactionalMistake {

    @Transactional(rollbackFor = XXXException.class)
    public void method() throws XXXException {

    }

}

5. 数据库引擎不支持事务

这个来源于一个读者反馈的例子，代码跟我的案例一摸一样，我这边是好的，但他就是不回滚。

后来排查出来是因为漏了一个关键属性的配置：

spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect

这里的spring.jpa.database-platform配置主要用来设置hibernate使用的方言。这里特地采用了MySQL5InnoDBDialect，主要为了保障在使用Spring Data JPA时候，Hibernate自动创建表的时候使用InnoDB存储引擎，不然就会以默认存储引擎MyISAM来建表，而MyISAM存储引擎是没有事务的。

如果你的事务没有生效，那么可以看看创建的表，是不是使用了MyISAM存储引擎，如果是的话，那就是这个原因了！

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

使用 @Transactional 时常犯的N种错误

1. 在同一个类中调用

2. @Transactional修饰方法不是public

3. 不同的数据源

4. 回滚异常配置不正确

5. 数据库引擎不支持事务