Seata AT 模式和 Spring @Transactional 注解连用时需要注意什么 ？

Seata AT 模式与 Spring @Transactional 注解连用时的注意事项：

• 使用Seata AT模式时，若要与Spring的@Transactional注解一起工作，需确保Seata的事务管理器成为Spring事务管理的一部分，一般通过配置Seata的事务增强器来实现。另外注意以下几点：
  • 确保在开启Seata事务的类或方法上不同时使用多个不同的事务管理策略，避免事务管理冲突。
  • Seata的事务边界可能需要手动控制，特别是在嵌套事务场景下，防止Spring事务提前提交导致Seata事务管理失效。
  • 如果使用Spring Boot，需要配置数据源代理，并正确设置事务隔离级别和传播行为，以便Seata能有效管理分布式事务。

Seata AT（Automatic Transaction）模式和Spring @Transactional 注解连用时，需要注意以下几点：

1. 事务管理器配置：

   • Seata与Spring的本地事务管理机制不同，需要确保Seata对DataSource进行了代理，并正确配置了事务管理器。使用Seata时通常会引入seata-spring-boot-starter依赖来自动处理数据源代理。

2. 注解使用位置：

   • Spring中的@Transactional注解通常用来管理本地数据库事务，而Seata AT模式下，全局事务由Seata服务端统一协调。在业务方法上同时使用时，要明白@Transactional针对的是局部事务，而Seata是全局事务协调者，两者结合时，Seata会接管本地事务的生命周期。

3. 一阶段和二阶段提交：

   • 在AT模式下，Seata会对业务SQL进行拦截，并在一阶段生成undo_log记录，在本地事务中一起提交。二阶段根据全局事务状态决定提交或回滚，此时无需在业务代码中显式使用@Transactional来控制事务边界，因为Seata已经通过两阶段提交协议实现了分布式事务的完整性。

4. 避免嵌套事务问题：

   • 如果在Seata AT模式下业务方法内部还有其他@Transactional注解的方法调用，由于Seata事务优先级较高，内部的Spring事务可能不会生效或者被合并到Seata的全局事务中。

5. 幂等性和异常处理：

   • Try阶段的操作应当设计成幂等的，因为Seata可能会重新尝试提交或回滚操作。
   • 要注意在Cancel（补偿）阶段执行失败的情况，需要有额外的补偿措施以保证数据一致性。

6. 隔离级别和传播属性：

   • @Transactional注解中的隔离级别、传播属性等在分布式事务场景下可能需要特别关注，但Seata框架自身也提供了相应的分布式事务隔离能力，实际使用时需结合具体业务场景权衡是否需要在本地事务层面上调整这些属性。

7. 方法可见性：

   • 如常规Spring事务一样，@Transactional注解只有在public可见的方法上才会生效，如果将此注解放在protected、private或其他非public修饰的方法上，则该事务注解不会产生作用。

总之，在使用Seata AT模式时，Spring的@Transactional注解更多地是对单体应用内数据库事务的一种辅助管理手段，而在分布式事务环境下，关键在于理解并配合Seata提供的全局事务管理机制。

@Transactional 可与 DataSourceTransactionManager 和 JTATransactionManager 连用分别表示本地事务和XA分布式事务，大家常用的是与本地事务结合。当与本地事务结合时，@Transactional和@GlobalTransaction连用，@Transactional 只能位于标注在@GlobalTransaction的同一方法层次或者位于@GlobalTransaction 标注方法的内层。这里分布式事务的概念要大于本地事务，若将 @Transactional 标注在外层会导致分布式事务空提交，当@Transactional 对应的 connection 提交时会报全局事务正在提交或者全局事务的xid不存在。
此回答整理自钉群“3群-Apache Seata(incubating) 开源讨论群”