事务传播行为

事务传播行为定义了当一个事务方法被另一个事务方法调用时，Spring应该如何处理事务边界。正确理解和使用事务传播行为对于开发健壮的企业应用至关重要。

什么是事务传播行为

当服务层方法之间相互调用时，Spring需要决定：

是否应该创建新事务
是否应该重用现有事务
如何处理嵌套的事务场景

事务传播行为正是控制这些决策的机制，它定义了方法对事务的参与方式。

Spring支持的七种传播行为

Spring在org.springframework.transaction.annotation.Propagation枚举中定义了七种事务传播行为：

1. REQUIRED (默认)

java

@Transactional(propagation = Propagation.REQUIRED)

行为: 如果当前存在事务，则加入该事务；如果不存在事务，则创建新事务。
适用场景: 大多数业务方法的默认选择。
示例:

java

@Service
public class OrderService {
    
    @Autowired
    private ProductService productService;
    
    @Transactional(propagation = Propagation.REQUIRED)
    public void createOrder(Order order) {
        saveOrder(order);
        // productService.updateStock方法也使用REQUIRED
        // 将在同一个事务中执行
        productService.updateStock(order.getItems());
    }
}

执行流程:

如果createOrder在事务外被调用，则创建新事务
如果updateStock方法被调用时，已经存在由createOrder创建的事务，则加入该事务
任何一个方法抛出异常，整个事务都会回滚

2. SUPPORTS

java

@Transactional(propagation = Propagation.SUPPORTS)

行为: 如果当前存在事务，则加入该事务；如果不存在事务，则以非事务方式执行。
适用场景: 对于可以在事务内外都能正常工作的方法，如简单查询。
示例:

java

@Service
public class ProductService {
    
    @Transactional(propagation = Propagation.SUPPORTS)
    public Product getProductById(Long id) {
        return productRepository.findById(id).orElse(null);
    }
}

执行流程:

如果getProductById在事务中被调用，则加入该事务
如果getProductById在事务外被调用，则以非事务方式执行

3. MANDATORY

java

@Transactional(propagation = Propagation.MANDATORY)

行为: 如果当前存在事务，则加入该事务；如果不存在事务，则抛出异常。
适用场景: 确保方法只在事务上下文中执行，防止意外的非事务调用。
示例:

java

@Service
public class PaymentService {
    
    @Transactional(propagation = Propagation.MANDATORY)
    public void processPayment(Payment payment) {
        // 必须在现有事务中执行
        paymentRepository.save(payment);
    }
}

执行流程:

如果processPayment在事务中被调用，则加入该事务
如果processPayment在事务外被调用，则抛出IllegalTransactionStateException

4. REQUIRES_NEW

java

@Transactional(propagation = Propagation.REQUIRES_NEW)

行为: 创建新事务，如果当前存在事务，则挂起当前事务。
适用场景: 需要独立于外部事务执行的操作，如日志记录、审计等。
示例:

java

@Service
public class AuditService {
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void logAction(String action, String user) {
        AuditLog log = new AuditLog(action, user, new Date());
        auditRepository.save(log);
    }
}

@Service
public class UserService {
    
    @Autowired
    private AuditService auditService;
    
    @Transactional
    public void updateUser(User user) {
        userRepository.save(user);
        // 即使updateUser事务回滚，审计日志也会被保存
        auditService.logAction("UPDATE_USER", user.getUsername());
    }
}

执行流程:

当updateUser方法调用logAction方法时，updateUser的事务被挂起
创建新事务执行logAction方法
logAction方法执行完成后，事务提交或回滚
恢复updateUser的事务并继续执行
如果updateUser后续抛出异常，只有updateUser的事务回滚，logAction的事务不受影响

5. NOT_SUPPORTED

java

@Transactional(propagation = Propagation.NOT_SUPPORTED)

行为: 以非事务方式执行，如果当前存在事务，则挂起当前事务。
适用场景: 长时间运行的只读操作，避免长时间持有事务资源。
示例:

java

@Service
public class ReportService {
    
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    public List<ReportData> generateReport() {
        // 耗时的报表生成逻辑，不需要事务
        return reportRepository.getReportData();
    }
}

执行流程:

如果generateReport在事务中被调用，则挂起该事务
以非事务方式执行generateReport方法
方法执行完成后，恢复之前挂起的事务

6. NEVER

java

@Transactional(propagation = Propagation.NEVER)

行为: 以非事务方式执行，如果当前存在事务，则抛出异常。
适用场景: 确保方法在非事务环境下执行，如一些特定的查询操作。
示例:

java

@Service
public class CacheService {
    
    @Transactional(propagation = Propagation.NEVER)
    public Object getCachedData(String key) {
        // 该方法不应该在事务上下文中被调用
        return cacheRepository.findByKey(key);
    }
}

执行流程:

如果getCachedData在事务中被调用，则抛出IllegalTransactionStateException
如果getCachedData在事务外被调用，则以非事务方式执行

7. NESTED

java

@Transactional(propagation = Propagation.NESTED)

行为: 如果当前存在事务，则创建嵌套事务；如果不存在事务，则创建新事务。
适用场景: 需要部分回滚能力的操作，如批处理部分可能失败的操作。
注意: 嵌套事务依赖于特定数据库的保存点支持，不是所有数据库都支持。
示例:

java

@Service
public class BatchService {
    
    @Autowired
    private ItemService itemService;
    
    @Transactional
    public void processBatch(List<Item> items) {
        for (Item item : items) {
            try {
                // 使用NESTED，如果单个item处理失败，只回滚该item的处理
                itemService.processItem(item);
            } catch (Exception e) {
                log.error("Error processing item: " + item.getId(), e);
                // 继续处理下一个item
            }
        }
    }
}

@Service
public class ItemService {
    
    @Transactional(propagation = Propagation.NESTED)
    public void processItem(Item item) {
        // 处理单个item的逻辑
        itemRepository.updateStatus(item);
    }
}

执行流程:

当processBatch调用processItem时，会在当前事务中创建一个嵌套事务（通过保存点实现）
如果processItem执行成功，继续处理下一个item
如果processItem抛出异常，只回滚到该item开始处理前的保存点，不影响其他item的处理
如果processBatch方法本身抛出异常，则整个事务回滚

传播行为的选择指南

常用传播行为选择

REQUIRED: 默认选择，适合大多数业务方法
REQUIRES_NEW: 用于必须独立于当前事务的操作
NESTED: 用于批处理中部分可能失败的操作
SUPPORTS: 用于查询方法，可以在事务内外执行

传播行为决策树

方法需要在事务中执行吗？
- 否 → 考虑 NOT_SUPPORTED 或 NEVER
- 是 → 继续
  - 需要在已存在的事务中执行吗？
    - 是 → 考虑 REQUIRED, SUPPORTS 或 MANDATORY
    - 否 → 继续
      - 需要创建新事务吗？
        是 → 考虑 REQUIRES_NEW
        否，但需要可以部分回滚 → 考虑 NESTED

常见问题与解决方案

1. 嵌套事务与REQUIRES_NEW的区别

NESTED:

使用保存点机制在现有事务内创建嵌套事务
子事务回滚不影响父事务
父事务回滚会导致子事务也回滚
子事务和父事务共享同一个物理事务连接

REQUIRES_NEW:

完全挂起当前事务，创建全新的独立事务
内部事务与外部事务完全隔离
使用独立的物理事务连接
性能开销较大（需要获取新的数据库连接）

2. 传播行为导致的死锁

使用REQUIRES_NEW可能增加死锁风险，当多个事务以不同顺序获取相同资源时：

java

@Service
public class OrderService {
    
    @Autowired
    private ProductService productService;
    @Autowired
    private InventoryService inventoryService;
    
    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
        // REQUIRES_NEW 可能导致死锁
        productService.updateProduct(order.getProductId());
        inventoryService.updateInventory(order.getProductId());
    }
}

@Service
public class InventoryService {
    
    @Autowired
    private ProductService productService;
    
    @Transactional
    public void processInventory(Long productId) {
        inventoryRepository.update(productId);
        // 与OrderService中的调用顺序相反，可能导致死锁
        productService.updateProduct(productId);
    }
}

解决方案:

保持一致的资源访问顺序
减少使用REQUIRES_NEW，尤其是在高并发场景
使用较短的事务超时时间
考虑使用乐观锁替代悲观锁

3. 事务传播与异常处理

注意异常处理对事务传播的影响：

java

@Service
public class UserService {
    
    @Autowired
    private EmailService emailService;
    
    @Transactional
    public void registerUser(User user) {
        userRepository.save(user);
        
        try {
            // REQUIRES_NEW
            emailService.sendWelcomeEmail(user);
        } catch (Exception e) {
            // 吞掉异常，不影响用户注册
            log.error("Failed to send email", e);
        }
    }
}

潜在问题:

如果emailService.sendWelcomeEmail使用REQUIRED，捕获异常后事务仍会标记为回滚
如果使用REQUIRES_NEW，则外部事务不受影响

最佳实践

默认使用REQUIRED: 除非有特殊需求，否则使用默认的REQUIRED传播行为
慎用REQUIRES_NEW: 它会创建独立事务，增加数据库连接消耗
避免事务方法自调用: 在同一个类中的方法调用不会触发事务代理
注意非公共方法: 事务注解在非public方法上不生效
一致的资源访问顺序: 避免死锁
测试事务行为: 编写测试验证事务在各种情况下的行为是否符合预期
理解传播行为与异常处理的关系: 异常处理会影响事务的提交和回滚

总结

事务传播行为是Spring事务管理的核心概念，它决定了方法间调用时事务的边界和行为。通过正确选择传播行为，可以实现灵活的事务控制，满足复杂业务场景的需求。

在实际开发中，大多数情况下默认的REQUIRED传播行为已经足够，但理解其他传播行为的特性和适用场景，可以帮助我们更好地设计和实现企业级应用的事务管理策略。对于复杂的事务需求，合理组合使用不同的传播行为，可以达到既保证数据一致性，又优化性能的效果。

事务传播行为 ​

什么是事务传播行为 ​

Spring支持的七种传播行为 ​

1. REQUIRED (默认) ​

2. SUPPORTS ​

3. MANDATORY ​

4. REQUIRES_NEW ​

5. NOT_SUPPORTED ​

6. NEVER ​

7. NESTED ​

传播行为的选择指南 ​

常用传播行为选择 ​

传播行为决策树 ​

常见问题与解决方案 ​

1. 嵌套事务与REQUIRES_NEW的区别 ​

2. 传播行为导致的死锁 ​

3. 事务传播与异常处理 ​

最佳实践 ​

总结 ​

事务传播行为

什么是事务传播行为

Spring支持的七种传播行为

1. REQUIRED (默认)

2. SUPPORTS

3. MANDATORY

4. REQUIRES_NEW

5. NOT_SUPPORTED

6. NEVER

7. NESTED

传播行为的选择指南

常用传播行为选择

传播行为决策树

常见问题与解决方案

1. 嵌套事务与REQUIRES_NEW的区别

2. 传播行为导致的死锁

3. 事务传播与异常处理

最佳实践

总结