Transactional 详解
1 .添加位置
1）接口实现类或接口实现方法上，而不是接口类中。
2）访问权限：public 的方法才起作用。@Transactional 注解应该只被应用到 public 方法上，这是由
Spring AOP 的本质决定的。
系统设计：将标签放置在需要进行事务管理的方法上，而不是放在所有接口实现类上：只读的接口就不
需要事务管理，由于配置了@Transactional就需要AOP拦截及事务的处理，可能影响系统性能。
3）错误使用：
1
1.接口中A、B两个方法，A无@Transactional标签，B有，上层通过A间接调用B，此时事务不生效。
2
3 2.接口中异常（运行时异常）被捕获而没有被抛出。 默认配置下，spring 只有在抛出的异常为运行时
unchecked 异常时才回滚该事务，
4 也就是抛出的异常为RuntimeException 的子类(Errors也会导致事务回滚)， 而抛出 checked 异常则不会
导致事务回滚 。
5 可通过 @Transactional rollbackFor进行配置。
6
7 3.多线程下事务管理因为线程不属于 spring 托管，故线程不能够默认使用 spring 的事务, 也不能获取
spring 注入的 bean 。
8 在被 spring 声明式事务管理的方法内开启多线程，多线程内的方法不被事务控制。 一个使用了
@Transactional 的方法，如果方法内包含多线程的使用，方法内部出现异常，
9 不会回滚线程中调用方法的事务。
\2. @Transactional注解
@Transactional 实质是使用了 JDBC 的事务来进行事务控制的
@Transactional 基于 Spring 的动态代理的机制
@Transactional 实现原理：
1
1) 事务开始时，通过AOP机制，生成一个代理connection对象， 并将其放入 DataSource 实例的某个
与 DataSourceTransactionManager 相关的某处容器中。
2 在接下来的整个事务中，客户代码都应该使用该 connection 连接数据库， 执行所有数据库命令。 [不
使用该 connection 连接数据库执行的数据库命令，
3 在本事务回滚的时候得不到回滚] （物理连接 connection 逻辑上新建一个会话session；
DataSource 与 TransactionManager 配置相同的数据源）
4
5 2) 事务结束时，回滚在第1步骤中得到的代理 connection 对象上执行的数据库命令， 然后关闭该代理
connection 对象。
6 （事务结束后，回滚操作不会对已执行完毕的SQL操作命令起作用）
3.声明式事务的管理实现本质：
事务的两种开启方式：
显示开启 start transaction | begin，通过 commit | rollback 结束事务
关闭数据库中自动提交 autocommit set autocommit = 0；MySQL 默认开启自动提交；通过手动提交
或执行回滚操作来结束事务
问题：
关闭自动提交后，若事务一直未完成，即未手动执行 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应用程序可以和这些命名服务和目录服
务之间进行交互
4.事务的隔离级别：
是指若干个并发的事务之间的隔离程度
1
1. @Transactional(isolation = Isolation.READ_UNCOMMITTED)：读取未提交数据(会出现脏读, 不可重
复读) 基本不使用
2 2. @Transactional(isolation = Isolation.READ_COMMITTED)：读取已提交数据(会出现不可重复读和幻
读)
3 3. @Transactional(isolation = Isolation.REPEATABLE_READ)：可重复读(会出现幻读)
4 4. @Transactional(isolation = Isolation.SERIALIZABLE)：串行化
5.事务传播行为：
如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为
1
1. TransactionDefinition.PROPAGATION_REQUIRED： 如果当前存在事务，则加入该事务；如果当前没
有事务，则创建一个新的事务。这是默认值。
2 2. TransactionDefinition.PROPAGATION_REQUIRES_NEW： 创建一个新的事务，如果当前存在事务，
则把当前事务挂起。
3 3. TransactionDefinition.PROPAGATION_SUPPORTS： 如果当前存在事务，则加入该事务；如果当前没
有事务，则以非事务的方式继续运行。
4 4. TransactionDefinition.PROPAGATION_NOT_SUPPORTED： 以非事务方式运行，如果当前存在事务，
则把当前事务挂起。
5 5. TransactionDefinition.PROPAGATION_NEVER： 以非事务方式运行，如果当前存在事务，则抛出异
常。
6 6. TransactionDefinition.PROPAGATION_MANDATORY： 如果当前存在事务，则加入该事务；如果当前
没有事务，则抛出异常。
7 7. TransactionDefinition.PROPAGATION_NESTED： 如果当前存在事务，则创建一个事务作为当前事务
的嵌套事务来运行； 如果当前没有事务，
8 则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。
6.其他：
1
1. 事务方法的嵌套调用会产生事务传播。
2 2. spring 的事务管理是线程安全的
3 3. 父类的声明的 @Transactional 会对子类的所有方法进行事务增强； 子类覆盖重写父类方式可覆盖其
@Transactional 中的声明配置。
4 4. 类名上方使用 @Transactional，类中方法可通过属性配置来覆盖类上的 @Transactional 配置； 比
如：类上配置全局是可读写，可在某个方法上改为只读。
如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。
如果不想终止，则必须捕获所有的运行时异常，决不让这个处理线程退出。队列里面出现异常数据了，
正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而影响下面对正常数据的处
理。
非运行时异常是RuntimeException以外的异常，类型上都属于Exception类及其子类。如IOException、
SQLException等以及用户自定义的Exception异常。对于这种异常，JAVA编译器强制要求我们必需对出
现的这些异常进行catch并处理，否则程序就不能编译通过。所以，面对这种异常不管我们是否愿意，只
能自己去写一大堆catch块去处理可能的异常。
