Understanding the Spring Framework’s Declarative Transaction Implementation

仅仅告诉您使用 @Transactional 注解注释您的类、将 @EnableTransactionManagement 添加到您的配置，并期望您了解其工作原理是不够的。为了提供更深入的了解，本节将在与事务相关的问题的上下文中阐述 Spring 框架声明式事务基础设施的内部工作原理。

It is not sufficient merely to tell you to annotate your classes with the @Transactional annotation, add @EnableTransactionManagement to your configuration, and expect you to understand how it all works. To provide a deeper understanding, this section explains the inner workings of the Spring Framework’s declarative transaction infrastructure in the context of transaction-related issues.

了解 Spring 框架声明式事务支持的最重要概念是，此支持在 via AOP proxies 中启用，并且事务建议由元数据（当前基于 XML 或注解）驱动。AOP 与事务元数据的组合产生一个 AOP 代理，它使用 TransactionInterceptor 结合适当的 TransactionManager 实现来在方法调用周围驱动事务。

The most important concepts to grasp with regard to the Spring Framework’s declarative transaction support are that this support is enabled via AOP proxies and that the transactional advice is driven by metadata (currently XML- or annotation-based). The combination of AOP with transactional metadata yields an AOP proxy that uses a TransactionInterceptor in conjunction with an appropriate TransactionManager implementation to drive transactions around method invocations.

Spring AOP 涵盖在 the AOP section 中。

Spring AOP is covered in the AOP section.

Spring 框架的 TransactionInterceptor 为命令式和响应式编程模型提供事务管理。拦截器通过检查方法返回类型来检测所需的事务管理方式。返回响应式类型（例如 Publisher 或 Kotlin Flow，或其子类型）的方法有资格进行响应式事务管理。包括 void 在内的所有其他返回类型都使用代码路径用于命令式事务管理。

Spring Framework’s TransactionInterceptor provides transaction management for imperative and reactive programming models. The interceptor detects the desired flavor of transaction management by inspecting the method return type. Methods returning a reactive type such as Publisher or Kotlin Flow (or a subtype of those) qualify for reactive transaction management. All other return types including void use the code path for imperative transaction management.

事务管理方式会影响所需的交易管理器。命令式事务需要 PlatformTransactionManager，而响应式事务使用 ReactiveTransactionManager 实现。

Transaction management flavors impact which transaction manager is required. Imperative transactions require a PlatformTransactionManager, while reactive transactions use ReactiveTransactionManager implementations.

@Transactional 通常与由 PlatformTransactionManager 管理的线程绑定事务一起使用，从而向当前执行线程内的所有数据访问操作公开事务。注意：这不传播到方法内新启动的线程。

@Transactional commonly works with thread-bound transactions managed by PlatformTransactionManager, exposing a transaction to all data access operations within the current execution thread. Note: This does not propagate to newly started threads within the method.

由 ReactiveTransactionManager 管理的响应式事务使用反应器上下文代替线程局部属性。因此，所有参与的数据访问操作都需要在同一个响应式管道中的同一个反应器上下文中执行。

A reactive transaction managed by ReactiveTransactionManager uses the Reactor context instead of thread-local attributes. As a consequence, all participating data access operations need to execute within the same Reactor context in the same reactive pipeline.

在使用 ReactiveTransactionManager 进行配置时，所有以事务划界的方法都应该返回一个响应式管道。void 方法或常规返回类型需要与常规 PlatformTransactionManager 相关联，例如通过相应 @Transactional 声明的 transactionManager 属性。

When configured with a ReactiveTransactionManager, all transaction-demarcated methods are expected to return a reactive pipeline. Void methods or regular return types need to be associated with a regular PlatformTransactionManager, e.g. through the transactionManager attribute of the corresponding @Transactional declarations.

下图显示了对事务代理的方法调用的概念视图：

The following image shows a conceptual view of calling a method on a transactional proxy: