所谓事务管理，其实就是“按照给定的事务规则来执行提交或者回滚操作”。
Spring 并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给 Hibernate 或者 JTA 等持久化机制所提供的相关平台框架的事务来实现。
Spring 事务管理器接口： org.springframework.transaction.PlatformTransactionManager ，通过这个接口，Spring 为各个平台如 JDBC(DataSourceTransactionManager)、Hibernate(HibernateTransactionManager)、JPA(JpaTransactionManager) 等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。
Spring 事务的分类
Spring 提供了两种事务管理方式：声明式事务管理和编程式事务管理。对不同的持久层访问技术，编程式事务提供一致的事务编程风格，通过模板化的操作一致性地管理事务；而声明式事务基于 Spring AOP 实现，却并不需要程序开发者成为 AOP 专家，亦可轻易使用 Spring 的声明式事务管理。
声明式事务
Spring 的声明式事务管理是建立在 Spring AOP 机制之上的，其本质是对目标方法前后进行拦截，并在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
简单地说，声明式事务是编程式事务 + AOP 技术包装，使用注解进行扫包，指定范围进行事务管理。声明式事务管理要优于编程式事务管理，这正是 Spring 倡导的非侵入式的开发方式。
示例：
@Transactional
public void transactionDemo {
// TODO 业务代码
}
编程式事务
在 Spring 出现以前，编程式事务管理对基于 POJO 的应用来说是唯一选择。我们需要在代码中显式调用 beginTransaction()、commit()、rollback() 等事务管理相关的方法，这就是编程式事务管理。
简单地说，编程式事务就是在代码中显式调用开启事务、提交事务、回滚事务的相关方法，因此代码侵入性较大。
示例：
@Autowired
private PlatformTransactionManager transactionManager;
public void transactionDemo() {
TransactionStatus transactionStatus = this.transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
// TODO 业务代码
// 提交事务
this.transactionManager.commit(transactionStatus);
} catch (Exception e) {
// 回滚事务
this.transactionManager.rollback(transactionStatus);
}
}
Spring 事务的原理
使用 AOP 环绕通知 和 异常通知。
注意： 在使用 Spring 事务时不能使用 try-catch 进行异常捕获，要将异常抛给外层，使其进行异常拦截，触发事务机制。
事务的传播行为
所谓事务的传播行为是指如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。事务传播行为是为了解决业务层方法之间互相调用的事务问题。
当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。
在 Spring 中有七种事务传播行为， 下面我们就来看看吧。
REQUIRED
如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。@Transactional 注解默认使用就是这个事务传播行为。 也就是说： - 如果外部方法没有开启事务的话，REQUIRED 修饰的内部方法会新开启自己的事务，且开启的事务相互独立，互不干扰。 - 如果外部方法开启事务并且被 REQUIRED 的话，所有 REQUIRED 修饰的内部方法和外部方法均属于同一事务，只要一个方法回滚，整个事务均回滚。
示例：
/**
* @author star
*/
public class ClassA {
@Transactional(propagation = Propagation.REQUIRED)
public void methoA() {
// TODO 业务代码
ClassB classB = new ClassB();
classB.methodB();
}
}
/**
* @author star
*/
public class ClassB {
@Transactional(propagation = Propagation.REQUIRED)
public void methodB() {
// TODO 业务代码
}
}
基于注解 @Transactional 声明事务失效分析
在开发过程中，可能会遇到使用 @Transactional 进行事务管理时出现失效的情况。这里我们的讨论是基于事务的默认传播行为是 REQUIRED。
常见失效场景
如果使用 MySQL 且引擎是 MyISAM，则事务会不起作用，原因是 MyISAM 不支持事务，改成 InnoDB 引擎则支持事务。
注解 @Trasactional 只能加在 public 修饰的方法上事务才起效。如果加在 protect、private 等非 public 修饰的方法上，事务将失效。
如果在开启了事务的方法内，使用了 try-catch 语句块对异常进行了捕获，而没有将异常抛到外层，事务将不起效。
在不同类之间的方法调用中，如果 A 方法开启了事务，B 方法没有开启事务，B 方法调用了 A 方法。如果 B 方法中发生异常，但不是调用的 A 方法产生的，则异常不会使 A 方法的事务回滚，此时事务无效。如果 B 方法中发生异常，异常是调用的 A 方法产生的，则 A 方法的事务回滚，此时事务有效。在 B 方法上加上注解 @Trasactional，这样 A 和 B 方法就在同一个事务里了，不管异常产生在哪里，事务都是有效的。
简单地说，不同类之间方法调用时，异常发生在无事务的方法中，但不是被调用的方法产生的，被调用的方法的事务无效。只有异常发生在开启事务的方法内，事务才有效。
在同一个类的方法之间调用中，如果 A 方法调用了 B 方法，不管 A 方法有没有开启事务， B 方法的事务是无效的。
如果使用了Spring + MVC，则 context:component-scan 重复扫描问题可能会引起事务失效。
原因分析
在应用系统调用声明 @Transactional 的目标方法时，Spring Framework 默认使用 AOP 代理，在代码运行时生成一个代理对象，再由这个代理对象来统一管理。
Spring 事务是使用 AOP 环绕通知和异常通知，就是对方法进行拦截，在方法执行前开启事务，在捕获到异常时进行事务回滚，在方法执行完成后提交事务。
最后
Spring 团队建议在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解，只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装。
Spring 文档中写到：Spring AOP 部分使用 JDK 动态代理或者 CGLIB 来为目标对象创建代理，如果被代理的目标对象实现了至少一个接口，则会使用 JDK 动态代理。所有该目标类型实现的接口都将被代理。若该目标对象没有实现任何接口，则创建一个CGLIB代理。
