Spring声明式与编程式事务的区别，事务与非事务方法相互调用导致的事务不生效问题

1. 事务的4种特性        

序号 参数 含义
1 原子性(Atomicity) 事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。
2 一致性(Consistemcy) 事务前后，数据库的状态都满足所有的完整性约束。
3 隔离性(Isolation) 并发执行的事务是隔离的，一个不影响一个。通过设置数据库的隔离级别，可以达到不同的隔离效果
4 持久性(Durability) 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

2.Transactional（）控制事务传播的配置项目（默认Propagation.REQUIRED）

@Transactional(propagation=Propagation.REQUIRED) //控制事务传播。默认是Propagation.REQUIRED
@Transactional(isolation=Isolation.DEFAULT) //控制事务隔离级别。默认跟数据库的隔离级别相同
@Transactional(readOnly=false) //控制事务可读写、只可读。默认可读写
@Transactional(timeout=30) //控制事务的超时时间，单位秒。默认跟数据库的事务控制系统相同
@Transactional(rollbackFor=RuntimeException.class) //控制事务遇到哪些异常会回滚。默认是RuntimeException
@Transactional(rollbackForClassName=RuntimeException) //同上
@Transactional(noRollbackFor=NullPointerException.class) //控制事务遇到哪些异常不会回滚。默认遇到RuntimeException回滚
@Transactional(noRollbackForClassName=NullPointerException)//同上

3.事务的7中传播特性

序号 传播行为 含义
1 REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。
2 SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行
3 MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。
4 NESTED 如果一个活动的事务存在，则运行在一个嵌套的事务中。如果没有活动事务，则按REQUIRED属性执行
5 NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常
6 REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个已经存在的事务挂起
7 NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务

Spring事务传播属性:
1.propagation-required: 支持当前事务,如果有就加入当前事务中;如果当前方法没有事务,就新建一个事务;
2.propagation-supports: 支持当前事务,如果有就加入当前事务中;如果当前方法没有事务,就以非事务的方式执行;
3.propagation-mandatory: 支持当前事务,如果有就加入当前事务中;如果当前没有事务,就抛出异常;
4.propagation-requires_new: 新建事务,如果当前存在事务,就把当前事务挂起;如果当前方法没有事务,就新建事务;
5.propagation-not-supported: 以非事务方式执行,如果当前方法存在事务就挂起当前事务;如果当前方法不存在事务,就以非事务方式执行;
6.propagation-never: 以非事务方式执行,如果当前方法存在事务就抛出异常;如果当前方法不存在事务,就以非事务方式执行;
7.propagation-nested: 如果当前方法有事务,则在嵌套事务内执行;如果当前方法没有事务,则与required操作类似;
前六个策略类似于EJB CMT，第七个（PROPAGATION_NESTED）是Spring所提供的一个特殊变量。
它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为（如Spring的DataSourceTransactionManager）
在同一个类中，一个方法调用另外一个有注解（比如@Async，@Transational）的方法，注解是不会生效的

4. 事务的传播案例：

事务在A类的a()方法中调用B类的b()方法的传播案例

A.a() B.b()的事务配置 a()没有事务的结果 a()有事务的结果
REQUIRED b()创建自己的事务; b()接受a()的事务
SUPPORTS b()不创建自己的事务; b()接受a()的事务
MANDATORY b()报异常 b()接受a()的事务
NESTED b()创建自己的事务; b()接受a()的事务，成为a()嵌套的子事务
NEVER b()不创建自己的事务; b()报异常
REQUIRES_NEW b()创建自己的事务; b()不接受a()的事务，b()先执行,内层事务失败不会影响外层事务
NOT_SUPPORTED b()不创建自己的事务; b()不接受a()的事务，b()先执行

编程式事务

基于底层的API，如PlatformTransactionManager、TransactionDefinition 和 TransactionTemplate 等核心接口，开发者完全可以通过编程的方式来进行事务管理。

编程式事务方式需要是开发者在代码中手动的管理事务的开启、提交、回滚等操作。

public void test() {
      TransactionDefinition def = new DefaultTransactionDefinition();
      TransactionStatus status = transactionManager.getTransaction(def);
       try {
         // 事务操作
         // 事务提交
         transactionManager.commit(status);
      } catch (DataAccessException e) {
         // 事务提交
         transactionManager.rollback(status);
         throw e;
      }
}

如以上代码，开发者可以通过API自己控制事务。

声明式事务

声明式事务管理方法允许开发者配置的帮助下来管理事务，而不需要依赖底层API进行硬编码。开发者可以只使用注解或基于配置的 XML 来管理事务。

@Transactional
public void test() {
     // 事务操作  
}

如上，使用@Transactional即可给test方法增加事务控制。当然，想要使用事务还需要一些配置内容。

声明式事务的优缺点

优点：

声明式事务帮助我们节省了很多代码，他会自动帮我们进行事务的开启、提交以及回滚等操作。

声明式事务管理使用了 AOP 实现的，本质就是在目标方法执行前后进行拦截。 在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。

使用这种方式，对代码没有侵入性，方法内只需要写业务逻辑就可以了。

缺点：

声明式事务有一个局限，那就是他的最小粒度要作用在方法上。除此之外，还有几种场景下会导致声明式事务不生效。

关于@Transactional的用法，阿里巴巴出的Java开发手册有提到过：

如以下几种场景就可能导致声明式事务失效：

1、@Transactional 应用在非 public 修饰的方法上

2、@Transactional 注解属性 propagation 设置错误

3、@Transactional 注解属性 rollbackFor 设置错误

4、同一个类中方法调用，导致@Transactional失效

5、异常被catch捕获导致@Transactional失效

6、数据库引擎不支持事务

问题一：数据库层面

数据库使用的存储引擎是否支持事务？默认情况下 MySQL 数据库使用的是 Innodb 存储引擎（5.5 版本之后），它是支持事务的，但是如果你的表特地修改了存储引擎，例如，你通过下面的语句修改了表使用的存储引擎为 MyISAM，而 MyISAM 又是不支持事务的

alter table table_name engine=myisam;


这样就会出现 “事务失效” 的问题了

「解决方案」：修改存储引擎为 Innodb。

问题二：未将 Bean 交由 Spring 进行管理

使用 Spring 的声明式事务，那么需要执行事务的 Bean 是否已经交由了 Spring 管理？在代码中的体现就是类上是否有 @Service、Component 等一系列注解

「解决方案」：添加 @Service 注解

问题二：非 public 的方法添加事务

默认情况下你无法使用 @Transactional 对一个非 public 的方法进行事务管理

「解决方案」：修改需要事务管理的方法为 public。

问题三：同一个类方法自调用

在一个Service内部，事务方法之间的嵌套调用，普通方法和事务方法之间的嵌套调用，都不会开启新的事务.是因为spring采用动态代理机制来实现事务控制，而动态代理最终都是要调用原始对象的，而原始对象在去调用方法时，是不会再触发代理了！

3.1、非事务方法A调用事务方法B，方法B事务不生效

@Service
public class DmzService {
public void saveAB(A a, B b) {
saveA(a);
saveB(b);
}
@Transactional
public void saveA(A a) {
dao.saveA(a);
}
@Transactional
public void saveB(B b){
dao.saveB(a);
}
}

Spring 中事务的实现是依赖于 AOP的，当容器在创建 dmzService 这个 Bean 时，发现这个类中存在了被 @Transactional 标注的方法（修饰符为 public）那么就需要为这个类创建一个代理对象并放入到容器中，创建的代理对象等价于下面这个类

public class DmzServiceProxy {
private DmzService dmzService;
public DmzServiceProxy(DmzService dmzService) {
this.dmzService = dmzService;
}
public void saveAB(A a, B b) {
dmzService.saveAB(a, b);
}
public void saveA(A a) {
try {
// 开启事务
startTransaction();
dmzService.saveA(a);
} catch (Exception e) {
// 出现异常回滚事务
rollbackTransaction();
}
// 提交事务
commitTransaction();
}
public void saveB(B b) {
try {
// 开启事务
startTransaction();
dmzService.saveB(b);
} catch (Exception e) {
// 出现异常回滚事务
rollbackTransaction();
}
// 提交事务
commitTransaction();
}
}

上面是一段伪代码，通过 startTransaction、rollbackTransaction、commitTransaction 这三个方法模拟代理类实现的逻辑。因为目标类 DmzService 中的 saveA 跟 saveB 方法上存在 @Transactional 注解，所以会对这两个方法进行拦截并嵌入事务管理的逻辑，同时 saveAB 方法上没有 @Transactional，相当于代理类直接调用了目标类中的方法。

spring默认的是PROPAGATION_REQUIRED机制，如果方法A标注了注解@Transactional 是完全没问题的，执行的时候传播给方法B，因为方法A开启了事务，线程内的connection的属性autoCommit=false，并且执行到方法B时，事务传播依然是生效的，得到的还是方法A的connectio，autoCommit还是为false，所以事务生效；反之，如果方法A没有注解@Transactional 时，是不受事务管理的，autoCommit=true，那么传播给方法B的也为true，执行完自动提交，即使B标注了@Transactional ；

我们会发现当通过代理类调用 saveAB 时整个方法的调用链如下：

实际上我们在调用 saveA 跟 saveB 时调用的是目标类中的方法，这种清空下，事务当然会失效。

3.2、在事务方法A中调用另外一个事务方法B，被调用方法B的事务没起作用

@Service
public class DmzService {
@Transactional
public void save(A a, B b) {
saveB(b);
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveB(B b){
dao.saveB(a);
}
}

实际上在调用 saveB 方法时，是直接调用的目标类中的 saveB 方法，在 saveB 方法前后并不会有事务的开启或者提交、回滚等操作，实际的流程是下面这样的

由于 saveB 方法实际上是由 dmzService 也就是目标类自己调用的，所以在 saveB 方法的前后并不会执行事务的相关操作。这也是自调用带来问题的根本原因：「自调用时，调用的是目标类中的方法而不是代理类中的方法」

3.3、自己注入自己，然后显示的调用

@Service
public class DmzService {
 // 自己注入自己
 @Autowired
 DmzService dmzService;
 
 @Transactional
 public void save(A a, B b) {
  dmzService.saveB(b);
 }
 @Transactional(propagation = Propagation.REQUIRES_NEW)
 public void saveB(B b){
  dao.saveB(a);
 }
}


3.4、把方法放到不同的类

开启一下 有关事务 的日志，在 配置文件 中加上下面的配置：

logging.level.org.springframework.jdbc.datasource.DataSourceTransactiOnManager=debug

我们需要新建一个接口：

public interface OtherService {
void SaveC(C c);
}


再定义一个类去实现这个接口：

@Service
public class OtherServiceImpl implements OtherService {
@Autowired
AccountMapper mapper;
@Override
@Transactional(propagation=Propagation.REQUIRES_NEW)
public void saveC(C c) {
mapper.insert(c);
}
}


修改原本的实现类：

@Service
public class DmzService {
 // 注入新建的类
 @Autowired
OtherService otherService;
 
 @Transactional
 public void save(C c) {
  otherService.savec(c);
 }
}


让我们再看看控制台的日志：

可以看到是开了两个事务去执行的。

这种解决方案最简单，不需要了解其他东西，但是这种方案需要修改代码结构，本来两个方法都是属于同一个类的，现在需要强行把它们拆开。

3.4、利用 AopContext

@Service
public class DmzService {
 @Transactional
 public void save(A a, B b) {
  ((DmzService) AopContext.currentProxy()).saveB(b);
 }
 @Transactional(propagation = Propagation.REQUIRES_NEW)
 public void saveB(B b){
  dao.saveB(a);
 }
}


使用上面这种解决方案需要注意的是，需要在配置类上新增一个配置

// exposeProxy=true代表将代理类放入到线程上下文中，默认是false
@EnableAspectJAutoProxy(exposeProxy = true)


我们的目标是要在实现类中获取本类的代理对象，Spring提供了Aop上下文，即：AopContext，通过AopContext，可以很方便的获取到代理对象：

@Service
public class AccountSerivceImpl implements AccountService {
@Autowired
AccountMapper mapper;
@Transactional
@Override
public void insertCodeBear() {
try {
((AccountService)AopContext.currentProxy()).insertCodeMonkey();
} catch (Exception ex) {
ex.printStackTrace();
}
Account account = new Account();
account.setAccount("CodeBear");
account.setPassword("CodeBear");
mapper.insert(account);
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void insertCodeMonkey() {
Account account = new Account();
account.setAccount("CodeMonkey");
account.setPassword("CodeMonkey");
mapper.insert(account);
int a = 1 / 0;
}
}


当写好代码，很愉快的去测试，发现竟然报错了:

翻译下：不能找到当前的代理，需要设置exposeProxy属性为 true使其可以。

expose字面意思就是 暴露。也就是说 我们需要允许暴露代理。

我们需要在Spring Boot启动类上+一个注解：

@EnableAspectJAutoProxy(exposeProxy = true)
@SpringBootApplication
@MapperScan(basePackages = "com.codebear.Dao")
public class SpringbootApplication {
public static void main(String[] args) throws Exception {
SpringApplication.run(SpringbootApplication.class, args);
}
}


再次运行：

3.5、 ApplicationContext：

@Service
public class AccountSerivceImpl implements AccountService {
@Autowired
AccountMapper mapper;
@Autowired
ApplicationContext context;
AccountService service;
@PostConstruct
private void setSelf() {
service = context.getBean(AccountService.class);
}
@Transactional
@Override
public void insertCodeBear() {
try {
service.insertCodeMonkey();
} catch (Exception e) {
e.printStackTrace();
}
Account account = new Account();
account.setAccount("CodeBear");
account.setPassword("CodeBear");
mapper.insert(account);
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void insertCodeMonkey() {
Account account = new Account();
account.setAccount("CodeMonkey");
account.setPassword("CodeMonkey");
mapper.insert(account);
int a = 1 / 0;
}
}


此方法不适用于prototype

在这里，我用了一个@PostConstruct注解，在初始化的时候，会调用被@PostConstruct标记的方法(注意，仅仅是初始化的时候，才会被调用。以后都不会被调用了，大家可以打个断点试一下)，这里这么做的目的就是为了提升一下效率，不用每次都getBean。所以如果这个类是prototype的，就不适用这个方法了。如果是prototype的话，就在insertCodeBear方法中使用getBean方法吧。

上两种方法比较方便，没有新建其他的接口或者是类，但是没有很好的封装获得Aop代理对象的过程，也不是很符合 迪比特法则，也就是最少知识原则。

3.6、 重写BeanPostProcessor接口：

关于这个接口是做什么的，这里就不详细阐述了，简单的来说这是Spring提供的接口，我们可以通过重写它，在初始化Bean之前或者之后，自定义一些额外的逻辑。
首先，我们需要定义一个接口：

public interface WeavingSelfProxy {
void setSelfProxy(Object bean);
}


要获得代理对象的类，需要去实现它：

@Service
public class AccountSerivceImpl implements AccountService, WeavingSelfProxy {
@Autowired
AccountMapper mapper;
AccountService service;
@Override
public void setSelfProxy(Object bean) {
System.out.println("进入到setSelfProxy方法");
service = (AccountService) bean;
}
@Transactional
@Override
public void insertCodeBear() {
try {
service.insertCodeMonkey();
} catch (Exception e) {
e.printStackTrace();
}
Account account = new Account();
account.setAccount("CodeBear");
account.setPassword("CodeBear");
mapper.insert(account);
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
@Override
public void insertCodeMonkey() {
Account account = new Account();
account.setAccount("CodeMonkey");
account.setPassword("CodeMonkey");
mapper.insert(account);
int a = 1 / 0;
}
}


重写BeanPostProcessor接口：

@Component
public class SetSelfProxyProcessor implements BeanPostProcessor {
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if(bean instanceof WeavingSelfProxy){
System.out.println("实现了WeavingSelfProxy接口");
((WeavingSelfProxy) bean).setSelfProxy(bean);
}
return bean;
}
} 事务回滚相关问题

回滚相关的问题可以被总结为两句话

1. 想回滚的时候事务却提交了

2. 想提交的时候被标记成只能回滚了（rollback only）

先看第一种情况：「想回滚的时候事务却提交了」。这种情况往往是程序员对 Spring 中事务的 rollbackFor 属性不够了解导致的。

Spring 默认抛出了未检查 unchecked 异常（继承自 RuntimeException 的异常）或者 Error 才回滚事务；其他异常不会触发回滚事务，已经执行的 SQL 会提交掉。如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定 rollbackFor 属性。

对应代码其实我们上篇文章也分析过了，如下：

回滚代码

以上代码位于：TransactionAspectSupport#completeTransactionAfterThrowing 方法中

默认情况下，只有出现 RuntimeException 或者 Error 才会回滚

public boolean rollbackOn(Throwable ex) {
    return (ex instanceof RuntimeException || ex instanceof Error);
}


所以，如果你想在出现了非 RuntimeException 或者 Error 时也回滚，请指定回滚时的异常，例如：

@Transactional(rollbackFor = Exception.class)


第二种情况：「想提交的时候被标记成只能回滚了（rollback only）」。

对应的异常信息如下：

Transaction rolled back because it has been marked as rollback-only


我们先来看个例子吧

@Service
public class DmzService {
 @Autowired
 IndexService indexService;
 @Transactional
 public void testRollbackOnly() {
  try {
   indexService.a();
  } catch (ClassNotFoundException e) {
   System.out.println("catch");
  }
 }
}
@Service
public class IndexService {
 @Transactional(rollbackFor = Exception.class)
 public void a() throws ClassNotFoundException{
  // ......
  throw new ClassNotFoundException();
 }
}


在上面这个例子中，DmzService 的 testRollbackOnly 方法跟 IndexService的 a 方法都开启了事务，并且事务的传播级别为 required，所以当我们在 testRollbackOnly 中调用 IndexService 的 a 方法时这两个方法应当是共用的一个事务。按照这种思路，虽然 IndexService 的 a 方法抛出了异常，但是我们在 testRollbackOnly 将异常捕获了，那么这个事务应该是可以正常提交的，为什么会抛出异常呢？

如果你看过我之前的源码分析的文章应该知道，在处理回滚时有这么一段代码

rollBackOnly 设置

在提交时又做了下面这个判断（这个方法我删掉了一些不重要的代码）

commit_rollbackOnly

可以看到当提交时发现事务已经被标记为 rollbackOnly 后会进入回滚处理中，并且 unexpected 传入的为 true。在处理回滚时又有下面这段代码

抛出异常

最后在这里抛出了这个异常。

以上代码均位于 AbstractPlatformTransactionManager 中

总结起来，「主要的原因就是因为内部事务回滚时将整个大事务做了一个 rollbackOnly 的标记」，所以即使我们在外部事务中 catch 了抛出的异常，整个事务仍然无法正常提交，并且如果你希望正常提交，Spring 还会抛出一个异常。

「解决方案」:

这个解决方案要依赖业务而定，你要明确你想要的结果是什么

1. 内部事务发生异常，外部事务 catch 异常后，内部事务自行回滚，不影响外部事务

将内部事务的传播级别设置为 nested/requires_new 均可。在我们的例子中就是做如下修改：

// @Transactional(rollbackFor = Exception.class,propagation = Propagation.REQUIRES_NEW)
@Transactional(rollbackFor = Exception.class,propagation = Propagation.NESTED)
public void a() throws ClassNotFoundException{
   // ......
   throw new ClassNotFoundException();
}


虽然这两者都能得到上面的结果，但是它们之间还是有不同的。当传播级别为 requires_new 时，两个事务完全没有联系，各自都有自己的事务管理机制（开启事务、关闭事务、回滚事务）。但是传播级别为 nested 时，实际上只存在一个事务，只是在调用 a 方法时设置了一个保存点，当 a 方法回滚时，实际上是回滚到保存点上，并且当外部事务提交时，内部事务才会提交，外部事务如果回滚，内部事务会跟着回滚。

1. 内部事务发生异常时，外部事务 catch 异常后，内外两个事务都回滚，但是方法不抛出异常

@Transactional
public void testRollbackOnly() {
   try {
      indexService.a();
   } catch (ClassNotFoundException e) {
      // 加上这句代码
      TransactionInterceptor.currentTransactionStatus().setRollbackOnly();
   }
}


通过显示的设置事务的状态为 RollbackOnly。这样当提交事务时会进入下面这段代码

显示回滚

最大的区别在于处理回滚时第二个参数传入的是 false, 这意味着回滚是回滚是预期之中的，所以在处理完回滚后并不会抛出异常。

读写分离一般有两种实现方式

1. 配置多数据源

2. 依赖中间件，如 MyCat

如果是配置了多数据源的方式实现了读写分离，那么需要注意的是：「如果开启了一个读写事务，那么必须使用写节点」，「如果是一个只读事务，那么可以使用读节点」

如果是依赖于 MyCat 等中间件那么需要注意：「只要开启了事务，事务内的 SQL 都会使用写节点（依赖于具体中间件的实现，也有可能会允许使用读节点，具体策略需要自行跟 DB 团队确认）」

基于上面的结论，我们在使用事务时应该更加谨慎，在没有必要开启事务时尽量不要开启。

一般我们会在配置文件配置某些约定的方法名字前缀开启不同的事务（或者不开启），但现在随着注解事务的流行，好多开发人员（或者架构师）搭建框架的时候在 service 类上加上了 @Transactional 注解，导致整个类都是开启事务的，这样严重影响数据库执行的效率，更重要的是开发人员不重视、或者不知道在查询类的方法上面自己加上 @Transactional（propagation=Propagation.NOT_SUPPORTED）就会导致，所有的查询方法实际并没有走从库，导致主库压力过大。

其次，关于如果没有对只读事务做优化的话（优化意味着将只读事务路由到读节点），那么 @Transactional 注解中的 readOnly 属性就应该要慎用。我们使用 readOnly 的原本目的是为了将事务标记为只读，这样当 MySQL 服务端检测到是一个只读事务后就可以做优化，少分配一些资源（例如：只读事务不需要回滚，所以不需要分配 undo log 段）。但是当配置了读写分离后，可能会可能会导致只读事务内所有的 SQL 都被路由到了主库，读写分离也就失去了意义。

参考：

@Transactional 同一个类中无事务方法a()内部调用有事务方法b()的问题：https://www.cnblogs.com/lukelook/p/11246180.html

6种@Transactional注解的失效场景：https://juejin.cn/post/6844904096747503629

被标记为事务的方法互相调用的坑（上）：https://www.jianshu.com/p/ba13144dba20?from=timeline&isappinstalled=0

被标记为事务的方法互相调用的坑（下）：https://www.jianshu.com/p/b375c52f2a71

一个 @Transaction 哪里来这么多坑：https://mp.weixin.qq.com/s/NjYsZu8vRvajWNrPCtLeFg

Spring官方都推荐使用的@Transactional事务，为啥我不建议使用！：https://mp.weixin.qq.com/s/owtAvBkjj44BVG7cFIZumw