Java声明式事务实战！工作中用这几种就够了！

文章会分为两个部分来讲解，第一部分是声明式事务的几种使用场景。第二部分包含事务没有生效，没有回滚的情况。

1.几种常用的事务传播行为

在实际的应用开发中，有几种事务传播行为比较常用，主要包括以下几种：

1. REQUIRED (默认行为): 这是最常用的传播行为。如果当前没有事务，就新建一个事务；如果已经存在事务，就加入这个事务。适用于大多数需要事务管理的场景，如任何需要保持数据完整性和一致性的操作。

2. REQUIRES_NEW: 始终启动一个新的事务。如果一个事务已经存在，则先将这个存在的事务挂起。这个传播行为适用于需要完全独立于当前事务上下文执行的操作，例如日志记录，这些操作不应该被外部事务的影响而回滚。

3. NESTED: 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则其行为与REQUIRED一样。嵌套事务是一个子事务，它依赖于父事务。父事务失败时，子事务会被回滚。子事务失败，父事务可以决定是回滚还是继续执行。这适用于需要执行一系列操作，其中一些操作可能需要独立于其它操作回滚的场景。

4. SUPPORTS: 如果当前存在事务，则加入事务；如果当前没有事务，则以非事务方式执行。这适用于不需要事务管理的读操作，但如果操作在事务环境中被调用，则能够参与到事务中。

5. NOT_SUPPORTED: 总是非事务地执行，并且挂起任何存在的事务。适用于不应该在事务环境中运行的长时间运行的操作。

但我个人认为前三种很好用，后面两种则看情况了，我没讲到的我认为用处不大，可以忽略。

1.1 REQUIRED

默认的传播行为就是没有就新建，否则就加入当前事务，一般在在方法上加@Transactional即可，（因为很简单就不放代码了，后续会放上代码）但注意该方法要被public修饰，否则事务不会生效，这个后面会细讲。

1.2 REQUIRES_NEW

我认为这个注解对于方法执行中加日志记录很有用，因为不管方法成功或者失败，我们都想记录下是哪里出了问题，此时就可以用到这个注解，点示例如下。

@Service
public class OrderService {

    @Autowired
    private LogService logService;

    @Transactional
    public void processOrder(Order order) {
        try {
            // ... 订单处理逻辑 ...

            // 模拟可能出现的异常
            if (someCondition) {
                throw new RuntimeException("订单处理出现异常");
            }

            // ... 更多订单处理逻辑 ...
        } catch (Exception e) {
            // 记录日志（即使主事务失败，日志事务仍然可以提交）
            logService.recordLog(order, e.getMessage());
            throw e; // 重新抛出异常以确保主事务可以回滚
        }
    }
}

@Service
public class LogService {

    @Autowired
    private LogRepository logRepository;

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void recordLog(Order order, String message) {
        LogEntry logEntry = new LogEntry();
        logEntry.setOrderId(order.getId());
        logEntry.setMessage(message);
        logEntry.setTimestamp(new Date());
        
        logRepository.save(logEntry); // 保存日志到数据库
    }
}

1.2 NESTED

这个注解提供了更完备的事务控制，试想这么一个场景，我的父方法需要被事务控制，子方法中出现了异常我也不回滚，但如果父方法中出现了异常，则全部事务回滚。

好好思考下这个场景，使用新建事务就做不到了，因为那已经是两个事务了，而嵌套事务则代表两个事务有关联，但子事务的优先级很低，以父方法中的代码为准，代码如下。

注意，我使用了noRollbackFor = InventoryException.class ，这将导致出现该异常，会往上抛，但是不回滚。

@Service
public class OrderService {

    @Autowired
    private InventoryService inventoryService;

    @Transactional(rollbackFor=Exception.class)
    public void processOrder(Order order) {
        try {
            // ... 订单处理逻辑 ...

            // 调用扣减库存方法，该方法在自己的嵌套事务中执行
            inventoryService.deductInventory(order);

            // ... 更多订单处理逻辑 ...

            // 模拟可能出现的异常
            if (someCondition) {
                throw new RuntimeException("订单处理出现异常");
            }

        } catch (Exception e) {
            // 处理异常，父事务中的异常会导致整个事务（包括嵌套事务）回滚
            throw e;
        }
    }
}

@Service
public class InventoryService {

    @Transactional(propagation = Propagation.NESTED, noRollbackFor = InventoryException.class)
    public void deductInventory(Order order) {
        // ... 库存扣减逻辑 ...

        // 如果出现特定条件，抛出自定义异常，这将只回滚当前嵌套事务
        if (someCondition) {
            throw new InventoryException("库存不足");
        }

        // ... 更多库存处理逻辑 ...
    }
}

2. 事务问题

2.1 事务不生效？

• public 方法：通常，只有标注在 public 方法上的 @Transactional 才会被
• Spring AOP代理捕获，因此才会生效。
  外部调用：Spring AOP基于代理模式，只有通过代理对象的外部调用方法时，事务才会被触发。如果在同一类中使用this关键字调用另一个方法（即使它被@Transactional注解），事务是不会被触发的。

所以只要满足了这两个条件，事务就一定会生效了。

2.2 事务不回滚？

• 异常的传播：只有当异常从标注了@Transactional的方法中抛出时，事务才会回滚。如果在方法内部通过try-catch块捕获了异常并处理了，那么事务不会自动回滚。
• 手动回滚：如果需要在catch块中回滚事务，可以通过调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()手动标记事务回滚。
• 运行时异常和错误：默认情况下，Spring只会在出现运行时异常（RuntimeException）或错误（Error）时回滚事务。
  所有异常回滚：如果需要让事务在检查型异常（即非运行时异常）抛出时也回滚，可以在@Transactional注解中设置rollbackFor = Exception.class。

以上就是我总结的事务内容，如果有什么错误，欢迎指正。

知识点是没有用的，体系是有用的，我们需要的是体系。