发布于 由admin

Spring Framework声明式事务回滚规则

好的，各位亲爱的程序员朋友们，今天咱们来聊聊Spring Framework里那让人又爱又恨的声明式事务回滚规则。这玩意儿，就像恋爱中的“分手复合条款”，用好了皆大欢喜，用不好，分分钟让你在代码的泥潭里挣扎。

咱们今天不搞那些枯燥的官方文档，咱用接地气儿的方式，把这回滚规则给它扒个精光，让它在你面前毫无秘密可言！准备好了吗？系好安全带，咱们发车啦！?

一、声明式事务：爱的魔力转圈圈？

首先，得搞明白啥是声明式事务。简单来说，就是你不用手动去写那些开启事务、提交事务、回滚事务的繁琐代码，而是通过配置（注解或者XML）告诉Spring：“嘿，这段代码很重要，要把它当成一个整体，要么一起成功，要么一起失败！”

这就像你去餐厅吃饭，你只管点菜、吃菜，至于后厨怎么炒菜、服务员怎么上菜、老板怎么算账，你完全不用操心。这就是声明式事务的魅力，把你的注意力从底层实现中解放出来，专注于业务逻辑。

那么，Spring是怎么知道哪些代码需要事务管理呢？答案就是AOP（面向切面编程）。Spring会像一个隐形的魔术师，在你标注了@Transactional注解的方法前后织入事务管理的逻辑。

二、回滚规则：分手复合的艺术

好了，进入正题。回滚规则，顾名思义，就是告诉Spring，在什么情况下，事务应该回滚，放弃之前的努力，回到最初的状态。这就像恋爱中，你设定了“不可触碰的底线”，一旦对方触碰，那就必须分手！?

默认情况下，Spring的声明式事务只会在遇到未检查异常（Unchecked Exception，也叫运行时异常，比如NullPointerException、ArrayIndexOutOfBoundsException等）时才会回滚。对于已检查异常（Checked Exception，比如IOException、SQLException等），Spring默认不会回滚。

这是为什么呢？因为Spring的设计哲学是：已检查异常通常是可预见的，程序员应该在代码中进行处理。如果遇到了已检查异常也回滚，那就意味着每次遇到文件找不到、数据库连接失败，都要回滚事务，这显然是不合理的。

三、@Transactional注解：掌控回滚的遥控器

@Transactional注解就是你掌控回滚规则的遥控器。它提供了rollbackFor和noRollbackFor两个属性，让你能够精确地控制哪些异常会导致回滚，哪些异常不会导致回滚。

  • rollbackFor：指定哪些异常会导致回滚

    rollbackFor属性接受一个Class数组，你可以把你想让它回滚的异常类都放进去。比如：

    @Transactional(rollbackFor = {IOException.class, SQLException.class})
public void myMethod() {
    // 业务逻辑
}

    这段代码的意思是，如果myMethod方法中抛出了IOException或SQLException，事务就会回滚。当然，如果抛出了IOException的子类异常，也会回滚，因为这是多态的特性嘛。

    这就像你跟女朋友说：“你要是再晚回家，我就跟你分手！”（晚回家是IOException，迟到是IOException的子类，那迟到肯定也算晚回家了！）

  • noRollbackFor：指定哪些异常不会导致回滚

    noRollbackFor属性和rollbackFor正好相反，它指定哪些异常即使抛出了，事务也不会回滚。比如：

    @Transactional(noRollbackFor = {MyCustomException.class})
public void myMethod() {
    // 业务逻辑
    throw new MyCustomException("This is a custom exception");
}

    这段代码的意思是，即使myMethod方法中抛出了MyCustomException，事务也不会回滚。

    这就像你跟女朋友说：“你要是犯了小错误，我不会跟你分手！”（小错误是MyCustomException，那就算犯了，也OK啦！）

四、rollbackFor和noRollbackFor的优先级：谁说了算？

如果rollbackFor和noRollbackFor同时存在，并且指向同一个异常类（或者存在继承关系），那么noRollbackFor的优先级更高。也就是说，即使你指定了rollbackFor包含某个异常，但如果同时又指定了noRollbackFor包含这个异常，那么事务最终也不会回滚。

这就像你跟女朋友说：“你要是再晚回家，我就跟你分手！但如果你是因为工作原因晚回家，那我就不跟你分手了！”（工作原因是noRollbackFor，晚回家是rollbackFor，但工作原因的晚回家优先级更高！）

五、RuntimeException和Exception：默认行为的秘密

现在咱们来揭秘一下Spring默认的回滚行为。其实，Spring的回滚规则是基于异常的类型来判断的。

  • RuntimeException及其子类：默认回滚

    RuntimeException及其子类（比如NullPointerException、IllegalArgumentException等）都属于未检查异常，Spring默认会回滚。

    这就像你跟女朋友说：“你要是无理取闹，我就跟你分手！”（无理取闹是RuntimeException，那肯定要分手！）

  • Exception及其子类（除了RuntimeException）：默认不回滚

    Exception及其子类（除了RuntimeException）都属于已检查异常，Spring默认不会回滚。

    这就像你跟女朋友说：“你要是生病了，我不会跟你分手！”（生病了是Exception，那肯定要照顾你啦！）

六、编程式事务：手动掌控命运

除了声明式事务，Spring还提供了编程式事务。编程式事务需要你手动编写代码来控制事务的开启、提交和回滚。虽然麻烦一些，但更加灵活，可以应对一些复杂的场景。

使用编程式事务，你可以通过TransactionTemplate或者PlatformTransactionManager来管理事务。这里咱们就不展开讲了，以后有机会再详细聊聊。

七、实战演练：代码说话

光说不练假把式，咱们来写一段代码，演示一下回滚规则的用法。

@Service
public class MyService {

    @Autowired
    private MyRepository myRepository;

    @Transactional(rollbackFor = {IOException.class})
    public void myMethod() throws IOException {
        try {
            myRepository.updateData("data1");
            // 模拟IOException
            if (true) {
                throw new IOException("Simulated IOException");
            }
            myRepository.updateData("data2"); // 这行代码不会执行
        } catch (IOException e) {
            System.out.println("IOException caught: " + e.getMessage());
            throw e; // 重新抛出异常，触发回滚
        }
    }

    @Transactional(noRollbackFor = {MyCustomException.class})
    public void myMethod2() throws MyCustomException {
        myRepository.updateData("data3");
        throw new MyCustomException("Simulated MyCustomException");
    }
}

@Repository
public class MyRepository {

    public void updateData(String data) {
        System.out.println("Updating data: " + data);
        // 模拟数据库操作
    }
}

class MyCustomException extends Exception {
    public MyCustomException(String message) {
        super(message);
    }
}

在这个例子中，myMethod方法标注了rollbackFor = {IOException.class}，所以当抛出IOException时，事务会回滚，data2不会被更新。myMethod2方法标注了noRollbackFor = {MyCustomException.class}，所以当抛出MyCustomException时，事务不会回滚，data3会被更新。

八、注意事项：细节决定成败

  • 异常的传播： 如果你在方法内部捕获了异常，并且没有重新抛出，那么事务就不会回滚。因为Spring认为你已经处理了异常，不需要回滚了。所以，如果你想让事务回滚，一定要把异常重新抛出。
  • 只读事务： 如果你的事务是只读事务（@Transactional(readOnly = true)），那么即使抛出了异常，事务也不会回滚。因为只读事务不允许修改数据，所以回滚没有意义。
  • 嵌套事务： 如果你的方法调用了另一个带有@Transactional注解的方法，那么就涉及到嵌套事务。嵌套事务的回滚规则比较复杂，需要根据事务的传播行为（propagation behavior）来判断。这里咱们就不展开讲了，以后有机会再详细聊聊。

九、总结：掌握回滚规则，掌控事务命运

好了，各位朋友们，咱们今天就聊到这里。希望通过今天的讲解，你对Spring Framework的声明式事务回滚规则有了更深入的了解。记住，掌握回滚规则，才能真正掌控事务的命运！

最后，送给大家一句箴言：代码虐我千百遍，我待代码如初恋！ 祝大家编程愉快！?

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注