1.编程中为什么用spring?声明式事声明式事
2.「译」Spring 事务管理：@Transactional 深度解析｜by MarcoBehler.md
3.SpringBoot源码之旅——事务
4.为什么spring中AOP 用的很少
5.@Transactional 详解
6.Spring事务注解@Transactional原理解析

编程中为什么用spring?

       1、Spring能有效地组织你的源码源码中间层对象；

       2、Spring能消除在许多工程中常见的声明式事声明式事对Singleton的过多使用；

       3、 通过一种在不同应用程序和项目间一致的源码源码方法来处理配置文件，消除各种自定义格式的声明式事声明式事属性文件的需要，仅仅需要看看类的源码源码源码下载电影爱情JavaBean属性。Inversion of Control的声明式事声明式事使用帮助完成了这种简化；（使用的是type2的IoC）

       4、 能够很容易培养你面向接口而不是源码源码面向类的编程习惯。

       5、声明式事声明式事 Spring的源码源码设计会让使用它创建的应用尽可能少的依赖于它的APIs，在Spring应用中的声明式事声明式事大多数业务对象没有依赖于Spring。

       6、源码源码 使用Spring构建的声明式事声明式事应用程序易于单元测试；

       7、 Spring使EJB成为一个实现选择，源码源码而不是声明式事声明式事必需的选择。你可以用POJOs或local EJBs来实现业务接口，却不会影响到调用代码。

       8、 Spring提供一些web应用上的EJB的替代方案，比如用AOP提供声明性事务管理；

       9、 Spring为数据存取提供了一个一致的框架，不论是使用JDBC还是O/R mapping的产品（Hibernate，JDO）。

       、 也是个人体会最深的一点，它可以替代部分配置文件，甚至有效减少源代码的编写量。

       1）方便解耦，简化开发（高内聚、低耦合）；

       Spring就是一个大工厂，可以将所有对象创建和依赖关系维护，交给Spring管理。

       2）AOP编程的支持；

       Spring提供面向切面编程，可以方便的实现对程序进行权限拦截、运行监控等功能，声明式事务的支持，只需要通过配置就可以完成对事务的管理，而无需手动编程。

       3）方便集成各种优秀框架；

       Spring不排斥各种优秀的开源框架，其内部提供了对各种优秀框架（如：Struts、Hibernate、MyBatis等）的直接支持。

       4）降低JavaEE API的使用难度；

       Spring 对JavaEE开发中非常难用的一些API（JDBC、JavaMail、远程调用等），都提供了封装，使这些API应用难度大大降低。定制app源码

「译」Spring 事务管理：@Transactional 深度解析｜by MarcoBehler.md

       原文链接为： Spring Transaction Management: @Transactional In-Depth | MarcoBehler

       你可以通过本文，对@Transactional 注解在 Spring 事务管理中的运行机制，形成一个简明实用的理解。

       唯一的阅读前提？你需要对数据库 ACID 原则有个大致了解，即数据库事务是什么，我们为什么需要它。此外，本文没有覆盖分布式事务和反应式事务（reactive transactions），尽管在 Spring 中下文提到的一些通用原则也是适用的。

       在本文中，你将学到 Spring 事务抽象框架的核心概念，同时会有很多示例代码帮助你理解。

       相对于 Spring 官方文档，本文不会让你迷失在 Spring 的上层概念里。 相反你会以不同寻常的路径来学习 Spring 事务管理。从底层开始，一层层向上。也就是说，你将从普通原始的 JDBC 事务学起。

       普通的 JDBC 事务是如何工作的？如何 start, commit 或 rollback JDBC 事务？最终，他们都做了同样的事来开启和关闭（或称为“管理”）数据库事务。纯 JDBC 事务管理代码如下：这 4 行高度简化的代码，就是 Spring@Transactional 为你在背后做的所有事情。在下一章节中，你将会学到他们是如何工作的。在此之前，我们还有一丁点知识点要补充。

       如何使用 JDBC 隔离级别和保存点（savepoints）？如果你已经使用过 Spring@Transactional 注解，你可能碰到过类似用法：我们会在后文更加详细的介绍 Spring 嵌套事务和隔离级别，在这重复提及，是因为这些参数最终可提炼成如下 JDBC 代码：

       Spring 或 Spring Boot 的事务是如何工作的？既然现在你对 JDBC 事务有了基础的理解，让我们再去探究下纯粹的 Spring 核心事务。这里所讲都可 1:1 适用于 Spring Boot 和 Sring MVC，但又做了一些补充。到底什么是 Spring 事务管理或事务抽象框架？记住，事务管理可简单理解为：Spring 如何 start, commit 或 rollback JDBC 事务？是不是听着和前文讲得很相似？抓住重点：基于 JDBC 你只有一个方法（setAutocommit(false)）来开启事务管理，Spring 提供了许多不同，但更方便的封装来做相同的事情。

       如何使用 Spring 编程式事务管理？最初，但现在很少使用方式，是在 Spring 通过编程定义事务：通过TransactionTemplate 或者直接使用 PlatformTransactionManager。代码示例如下「译者注：参见配套项目 BookingServcie 实现」：与 JDBC 示例 比较：尽管这是一个不小的改进，但编程式事务管理并不是 Spring 事务框架主要关注的。相反，声明式事务管理才是重头戏。让我们一探究竟

       如何使用 Spring 的仿体育源码@Transactional 注解（声明式事务管理）？让我们看下时下的 Spring 事务管理通常怎么用：这是怎么做到的？没有了冗余的 XML 配置和额外的编码。相反，你只需要做两件事：所以，为了让@Transactional 工作，你需要：现在，我说 Spring 透明的为你处理事务，到底在指什么？ 在有了 JDBC 事务示例 的知识储备后，@Transactional 标注的 UserService 可以翻译简化成：这个示例看起来像魔术，让我们继续探究下 Spring 是如何为你自动插入这些连接代码的。

       CGLIB & JDK 代理 - 在@Transactional 之下？Spring 不能真的像我上面做的那样，去重写你的 Java 类来插入连接代码（除非你使用字节码增强等高级技术，在这我们暂时忽略它）

       你的registerUser() 方法还是只是调用了 userDao.save(user)，这是无法实时改变的。但是 Spring 有它的优势。在核心层，它有一个 IoC 容器。它实例化一个UserService 单例并可自动注入到任何需要 UserService 的 Bean 中。不管何时你在一个 Bean 上使用@Transactional，Spring 使用了个小伎俩。它不是直接实例化一个 UserService 原始对象，而是一个 UserService 的事务代理对象。借助 Cglib library 的能力，它可以使用子类继承代理（proxy-through-subclassing）的方式来实现。当然还有其他方式可以构造代理对象（例如 Dynamic JDK proxies 「译者注：这要求代理对象有相应接口类」），这里暂不做展开。

       你的UserService 可以动态生成代理类，并且代理可以帮你管理事务。但是并不是代理类本身去处理事务状态（open，commit，close），而是委托给了事务管理器（transaction manager）。

       你的UserService 有一个 invoice() 事务方法。它调用了另外一个 InvoiceService 类上的 createPdf() 事务方法。然而从 Spring 看来，这里有 2 个逻辑事务存在：第一个在UserService，另外一个在 InvoiceService。Spring 足够智能知道让两个 @Transactional 标记的方法，在底层使用同一个物理数据库事务。

       更改事务传播模式为requires_new 告诉 Spring：createPDF() 需要在它自己的、独立于其他任何已经在的事务里执行。这意味着你的底层代码会打开 2（物理）连接/事务 到数据库。Spring 依旧能够机智的把 2 个 逻辑事务（ invoice()/createPdf() ）映射到两个不同的物理数据库事务上。

       每个 Spring 传播模式在 数据库或 JDBC 连接层面到底做了什么？练习： 在原始 Java 实现那节，我展示了 JDBC 能够对事务进行的所有操作。花几分钟思考下，每个 Spring 传播模式在数据库或 JDBC 连接层面到底做了什么。然后再看下下面的火花视频源码解答。

       答案：如你所见，大多数传播模式并没有在数据库或 JDBC 层面做什么事情。更多的是通过 Spring 来组织你的代码，告诉 Spring 如何/什么时候/哪里需要事务处理。

       在示例中，任何时候你调用UserService 的 myMethod() 方法，Spring 期望这里有一个打开的事务。它不会为自己开启，相反，在没有已开启事务的情况下调用方法，Spring 会抛出异常。请记住这 “逻辑事务处理”的补充知识点。

       @Transactional 上隔离级别（Isolation Levels）代表什么？这是个抖机灵的问题，但当你如下配置的时候，到底发生了什么？哈，这可以简单地等价于：然而数据库事务隔离级别，是一个复杂的主题，你需要自己花些时间去掌握。Pstgres 的官方文档中的 isolation levels 章节，是个不错的入门文档。

       最容易踩的@Transactional 的坑？这里有一个 Spring 新手经常踩的坑，看下如下代码：你有一个UserService 类，事务方法 invoice 内部调用了事务方法 createPdf()。所以，当有人调用invoice() 的时候，最终有个多少个物理事务被打开？答案不是 2 个，而是 1 个，为什么呢？让我们回到本文中代理那章节。Spring 为你创建了UserService 代理类，但代理类内部的方法调用，是无法被代理的。也就是说，没有新的事务为你生成。这里有技巧（例如： self-injection 「译者注：参见示例项目 InnerCallSercie」），可以帮助你绕过该限制。但主要收获是：始终牢记代理事务的边界。

       在 Spring Boot 或 Spring MVC 中使用@Transactional？我们目前只是讨论了纯粹的核心 Spring 上的用法。那在 Spring Boot 或 Spring MVC 中会有什么使用差异吗？答案是：没有。无论使用何种框架（或更确切地说：Spring 生态系统中的所有框架），您都将始终使用 @Transactional 注解，配合事务管理器，以及@EnableTransactionManagement 注解。没有其他用法了。但是，与 Spring Boot 的唯一区别是，通过 JDBC 自动配置，net 源码保护它会自动设置@EnableTransactionManagement 注解，并为你创建 PlatformTransactionManager。

       关于 Spring 回滚的部分，将会在下一次文章修订中补充。Spring Boot 内回滚是通过@Transactional 注解上 rollback 系列配置实现的，读者可查阅源码注释了解使用方式，注释还是写得很完备的，本质上也是根据配置条件，确定何时调用 commit，何时调用 rollback。

       Spring 和 JPA / Hibernate 事务管理是如何一起工作的？目标：同步 Spring@Transactional 和 Hibernate / JPA。在这个节点上，你期望 Spring 可以和其他数据库框架，类似 Hibernate（一个流行的 JPA 实现）或 Jooq 等整合。让我来看一个纯粹的 Hibernate 示例（注意：直接使用 Hibernate 还是通过 JPA 使用 Hibernate 都没关系）。用 Hibernate 将UserService 重写如下：然而上述代码有一个大问题：但最终我们还是可以将 Spring 和 Hibernate 无缝整合，也就是说他们其实可以理解对象的事务概念。代码如下：这是怎么做到的？使用 HibernateTransactionManager 有一个非常简单的解决此集成问题的方法：相比在 Spring 配置里使用 DataSourcePlatformTransactionManager，你可以替换成 HibernateTransactionManager（如果使用了原生 Hibernate）或 JpaTransactionManager（如果通过 JPA 使用了 Hibernate）。这个定制化的 HibernateTransactionManager 会确保：与往常一样，一图胜千言（不过请注意，代理和真实服务之间的流程在这被高度抽象和简化了）。

       理解 Spring 事务管理后，你应该对 Spring 框架是如何处理事务，以及如何应用于其他 Spring 类库（例如 Spring Boot 或 Spring WebMVC）有了一个很好的了解。最大的收获应是：最终使用哪种框架都无关紧要，这一切可以映射到 JDBC 的基础概念上。正确理解它们（记住：getConnection()，setAutocommit(false)，commit()），在以后碰到复杂的企业级项目的使用，你能更容易抓住本质。

       到目前为止，你已经对 Spring 事务管理有了全面的了解，希望你在实践中能够灵活运用这些知识，解决实际项目中的事务问题。感谢阅读。

SpringBoot源码之旅——事务

       事务是数据操作的逻辑单元，旨在确保数据一致性和操作隔离。它包括两个核心目标：数据一致性和操作隔离。数据一致性要求事务提交后，所有操作成功执行，更改永久生效；而操作隔离则确保多个并发事务独立执行，互不影响。

       事务管理资源不仅限于数据库，也涵盖了消息队列、文件系统等。通常讨论的事务主要指的是“数据库事务”。研究中，我们将围绕MySQL数据库和Spring声明式事务展开，但所涉及的事务概念、接口抽象和实现方式适用于更广泛的场景。

       在实现声明式事务时，关键概念包括ACID（原子性、一致性、隔离性、持久性）、隔离级别和事务传播机制。实现依赖于AOP（面向切面编程），通过环绕增强在目标方法执行前后启动或提交事务。

       事务增强通常涉及TransactionInterceptor，对于基于JDK接口动态代理的实现，要求方法必须为public或public final，且不能使用protected、private或static修饰。基于CGLib的字节码动态代理在扩展类时受限于final、static、private修饰符。

       事务管理的核心接口包括TransactionDefinition（描述事务属性）和TransactionStatus（表示事务状态），而PlatformTransactionManager则负责创建和管理事务行为。

       ThreadLocal机制用于共享数据库连接，确保同一线程内的操作在同一个事务中。不同线程下的嵌套调用则工作在独立事务中。

       声明式事务通过生成代理对象实现，Spring的MethodInterceptor接口在Bean方法调用时触发TransactionInterceptor。TransactionInterceptor在invoke方法中通过TransactionAspectSupport处理事务，支持声明式和编程式事务。

       事务传播机制中，Spring通过AbstractPlatformTransactionManager获取当前事务状态。在DataSourceTransactionManager的具体实现中，通过TransactionSynchronizationManager记录当前事务资源和同步回调，确保操作在一致的事务上下文中执行。

       TransactionSynchronizationManager通过ThreadLocal记录资源和同步信息，便于事务同步。在事务提交流程中，触发回调以精确控制事务操作的不同阶段。

       实现细节涉及流程图和具体的代码示例，这些内容有助于深入理解Spring事务管理的实现。参考资源包括网易云信的技术文章、柳树关于Spring事务的讲解，以及《精通Spring 4.x 企业应用开发实战》等书籍。

为什么spring中AOP 用的很少

       spring AOP不是用反射实现的，而bean的创建一般是这样做的。

        spring里主要通过Java动态代理接口、cglib生成子类、AspectJ这三种方式来实现AOP。

       é€šè¿‡AOP进行声明式事务管理应该是大家用的最多的吧。像权限校验和日志记录虽然也具备一定的横切性需求，但好像很少拿spring来做，权限控制框架倒是可以考虑与spring进行集成，细粒度的日志记录则根本无法真正利用AOP来做，原因在于业务方法记录日志的位置是不统一的，从而无法确定切入点。

       ä½†spring利用AOP还是干了不少事情的，随便翻看源码你都可以发现它们的影子。举个例子，spring里有一个javax.sql.DataSource的代理类TransactionAwareDataSourceProxy，它利用java的动态代理在运行时替换了原生DataSource的getConnection等诸多方法，最重要的是它使你的遗留系统具备了与spring集成并使用spring事务管理的能力，而这一切你只需要一个简单的配置，你并不知道spring在后台为你做了这些事情。

       AOP是一种很有用的编程理念，语言和工具不应成为我们程序员思想的束缚，即使项目不用spring AOP你也可以在适当的契机把spring里好的想法拿来用，甚至你觉得不好还可以改造它，这样我们才能真正成为工具的主人而不是奴仆。

@Transactional 详解

       @Transactional 是声明式事务管理编程中使用的注解

       1. 添加位置

       1）接口实现类或接口实现方法上，而不是接口类中。2）访问权限：public 的方法才起作用。@Transactional 注解应该只被应用到 public 方法上，这是由 Spring AOP 的本质决定的。系统设计：将标签放置在需要进行事务管理的方法上，而不是放在所有接口实现类上：只读的接口就不需要事务管理，由于配置了@Transactional就需要AOP拦截及事务的处理，可能影响系统性能。

       3）错误使用：

       1. 接口中A、B两个方法，A无@Transactional标签，B有，上层通过A间接调用B，此时事务不生效。2. 接口中异常（运行时异常）被捕获而没有被抛出。默认配置下，spring 只有在抛出的异常为运行时 unchecked 异常时才回滚该事务，也就是抛出的异常为RuntimeException 的子类(Errors也会导致事务回滚)，而抛出 checked 异常则不会导致事务回滚。可通过 @Transactional rollbackFor进行配置。3. 多线程下事务管理因为线程不属于 spring 托管，故线程不能默认使用 spring 的事务，也不能获取spring 注入的 bean。在被 spring 声明式事务管理的方法内开启多线程，多线程内的方法不被事务控制。一个使用了@Transactional 的方法，如果方法内包含多线程的使用，方法内部出现异常，不会回滚线程中调用方法的事务。

       2. 声明式事务管理实现方式：基于 tx 和 aop 名字空间的 xml 配置文件

       // 基本配置 // MyBatis 自动参与到 spring 事务管理中，无需额外配置，只要 org.mybatis.spring.SqlSessionFactoryBean 引用的数据源与 DataSourceTransactionManager 引用的数据源一致即可，否则事务管理会不起作用。 // 标签的声明，是在 Spring 内部启用 @Transactional 来进行事务管理，使用 @Transactional 前需要配置。

       3. @Transactional注解 @Transactional 实质是使用了 JDBC 的事务来进行事务控制的 @Transactional 基于 Spring 的动态代理的机制

       @Transactional 实现原理：1) 事务开始时，通过AOP机制，生成一个代理connection对象，并将其放入 DataSource 实例的某个与 DataSourceTransactionManager 相关的某处容器中。在接下来的整个事务中，客户代码都应该使用该 connection 连接数据库，执行所有数据库命令。[不使用该 connection 连接数据库执行的数据库命令，在本事务回滚的时候得不到回滚]（物理连接 connection 逻辑上新建一个会话session； DataSource 与 TransactionManager 配置相同的数据源）2) 事务结束时，回滚在第1步骤中得到的代理 connection 对象上执行的数据库命令，然后关闭该代理 connection 对象。（事务结束后，回滚操作不会对已执行完毕的SQL操作命令起作用）

       4. 声明式事务的管理实现本质：事务的两种开启方式：显示开启 start transaction | begin，通过 commit | rollback 结束事务 关闭数据库中自动提交 autocommit set autocommit = 0；MySQL 默认开启自动提交；通过手动提交或执行回滚操作来结束事务

       Spring 关闭数据库中自动提交：在方法执行前关闭自动提交，方法执行完毕后再开启自动提交

       // org.springframework.jdbc.datasource.DataSourceTransactionManager.java 源码实现 // switch to manual commit if necessary. this is very expensive in some jdbc drivers, // so we don't want to do it unnecessarily (for example if we've explicitly // configured the connection pool to set it already). if (con.getautocommit()) { txobject.setmustrestoreautocommit(true); if (logger.isdebugenabled()) { logger.debug("switching jdbc connection [" + con + "] to manual commit"); } con.setautocommit(false); }

       问题：

       关闭自动提交后，若事务一直未完成，即未手动执行 commit 或 rollback 时如何处理已经执行过的SQL操作？

       C3P0 默认的策略是回滚任何未提交的事务 C3P0 是一个开源的JDBC连接池，它实现了数据源和 JNDI 绑定，支持 JDBC3 规范和 JDBC2 的标准扩展。目前使用它的开源项目有 Hibernate，Spring等 JNDI(Java Naming and Directory Interface,Java命名和目录接口)是SUN公司提供的一种标准的Java命名系统接口，JNDI提供统一的客户端API，通过不同的访问提供者接口JNDI服务供应接口(SPI)的实现，由管理者将JNDI API映射为特定的命名服务和目录系统，使得Java应用程序可以和这些命名服务和目录服务之间进行交互

       ------------------------------------------------------------------------------------------------------------------------------- 5. spring 事务特性 spring 所有的事务管理策略类都继承自 org.springframework.transaction.PlatformTransactionManager 接口

       public interface PlatformTransactionManager { TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException; void commit(TransactionStatus status) throws TransactionException; void rollback(TransactionStatus status) throws TransactionException; }

       事务的隔离级别：是指若干个并发的事务之间的隔离程度

       1. @Transactional(isolation = Isolation.READ_UNCOMMITTED)：读取未提交数据(会出现脏读, 不可重复读) 基本不使用 2. @Transactional(isolation = Isolation.READ_COMMITTED)：读取已提交数据(会出现不可重复读和幻读) 3. @Transactional(isolation = Isolation.REPEATABLE_READ)：可重复读(会出现幻读) 4. @Transactional(isolation = Isolation.SERIALIZABLE)：串行化

       事务传播行为：如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为

       1. TransactionDefinition.PROPAGATION_REQUIRED： 如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是默认值。2. TransactionDefinition.PROPAGATION_REQUIRES_NEW： 创建一个新的事务，如果当前存在事务，则把当前事务挂起。3. TransactionDefinition.PROPAGATION_SUPPORTS： 如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。4. TransactionDefinition.PROPAGATION_NOT_SUPPORTED： 以非事务方式运行，如果当前存在事务，则把当前事务挂起。5. TransactionDefinition.PROPAGATION_NEVER： 以非事务方式运行，如果当前存在事务，则抛出异常。6. TransactionDefinition.PROPAGATION_MANDATORY： 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。7. TransactionDefinition.PROPAGATION_NESTED： 如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

       上表字段说明：

       1. value ：主要用来指定不同的事务管理器；主要用来满足在同一个系统中，存在不同的事务管理器。比如在Spring中，声明了两种事务管理器txManager1, txManager2。然后，用户可以根据这个参数来根据需要指定特定的txManager。2. value 适用场景：在一个系统中，需要访问多个数据源或者多个数据库，则必然会配置多个事务管理器。3. REQUIRED_NEW：内部的事务独立运行，在各自的作用域中，可以独立的回滚或者提交；而外部的事务将不受内部事务的回滚状态影响。4. ESTED 的事务，基于单一的事务来管理，提供了多个保存点。这种多个保存点的机制允许内部事务的变更触发外部事务的回滚。而外部事务在混滚之后，仍能继续进行事务处理，即使部分操作已经被混滚。由于这个设置基于 JDBC 的保存点，所以只能工作在 JDB C的机制。5. rollbackFor：让受检查异常回滚；即让本来不应该回滚的进行回滚操作。6. noRollbackFor：忽略非检查异常；即让本来应该回滚的不进行回滚操作。

Spring事务注解@Transactional原理解析

       事务管理是应用系统开发的关键部分，Spring 提供了丰富且方便的事务管理解决方案，显著简化了代码编写并提高了可维护性。

       以原生JDBC事务处理与Spring的事务处理进行对比，原生代码中充斥着复杂且重复的事务管理逻辑，而使用Spring则通过简单的注解即可实现。例如，针对保存三张表数据的需求（country、city、category），若采用原生JDBC，代码会显得冗长且难于维护。而在Spring中，通过设置特定的事务属性，如`Propagation.REQUIRES_NEW`，只需在对应方法上添加`@Transactional`注解，Spring便会自动处理事务，极大简化了代码。

       Spring的声明式事务机制，通过`TransactionAutoConfiguration`类自动配置事务相关组件，并由`TransactionInterceptor`类执行事务处理逻辑，实现了对带有`@Transactional`注解的方法的代理。此单例对象确保了所有事务逻辑的一致性和高效性。

       在使用`@Transactional`注解时，需要关注其属性的含义，包括`propagation`和`isolation`。`propagation`属性定义了事务的传播行为，如是否需要新事务、是否在当前事务中进行等。`isolation`属性则决定了事务的隔离级别，确保不同事务之间数据的一致性。

       进一步深入了解`@Transactional`注解的实现细节，可参阅Spring源码。GitHub和Gitee提供该代码的同步版本，方便开发者深入研究。

深入了解Spring中的@Transactional

       事务是不可分割的操作集合，确保数据的原子性、一致性、隔离性和持久性。Spring中事务管理支持编程式和声明式两种方式。

       编程式事务需要在代码中手动管理，而声明式事务则通过注解或XML配置实现。推荐使用声明式事务，其中@Transactional注解广泛用于标记事务操作。

       使用@Transactional注解标记方法时，需考虑propagation参数，该参数定义了事务的传播行为。方法A调用事务方法B时，事务传播到方法A中，propagation属性决定此行为。

       在声明式事务中，@Transactional注解利用Spring的AOP思想实现事务管理。Spring AOP将通用功能抽取为切面，避免代码侵入业务逻辑。在调用目标方法前，代理类插入切面，Spring在运行时将切面织入到管理的Bean中，实现方法的事务控制。

       了解Spring AOP的关键术语后，通过源码分析，可以看到Spring通过TransactionAutoConfiguration配置启用事务管理。@Transactional注解的实现涉及自动代理创建器和代理过程，最终生成代理对象以执行事务操作。

       总结而言，通过在方法上添加@Transactional注解并配置propagation参数，Spring能够实现声明式事务管理，利用AOP思想在运行时织入切面，确保方法执行的事务一致性。