Spring声明式与编程式事务的区别 _spring事务管理

如以下几种场景就可能导致声明式事务失效：
1、@ 应用在非修饰的方法上
2、@ 注解属性设置错误
3、@ 注解属性设置错误
4、同一个类中方法调用，导致@失效
5、异常被catch捕获导致@失效
6、数据库引擎不支持事务
问题一：数据库层面
数据库使用的存储引擎是否支持事务？默认情况下 MySQL 数据库使用的是存储引擎（5.5 版本之后），它是支持事务的，但是如果你的表特地修改了存储引擎，例如，你通过下面的语句修改了表使用的存储引擎为，而又是不支持事务的
alter table table_name engine=myisam;
这样就会出现 “事务失效” 的问题了
「解决方案」：修改存储引擎为。
问题二：未将 Bean 交由进行管理
使用的声明式事务，那么需要执行事务的 Bean 是否已经交由了管理？在代码中的体现就是类上是否有@、等一系列注解
「解决方案」：添加@注解
问题二：非的方法添加事务
默认情况下你无法使用@对一个非的方法进行事务管理
「解决方案」：修改需要事务管理的方法为。
问题三：同一个类方法自调用
在一个内部，事务方法之间的嵌套调用，普通方法和事务方法之间的嵌套调用，都不会开启新的事务.是因为采用动态代理机制来实现事务控制，而动态代理最终都是要调用原始对象的，而原始对象在去调用方法时，是不会再触发代理了！
3.1、非事务方法A调用事务方法B，方法B事务不生效
@Servicepublic class DmzService {public void saveAB(A a, B b) {saveA(a);saveB(b);}@Transactionalpublic void saveA(A a) {dao.saveA(a);}@Transactionalpublic void saveB(B b){dao.saveB(a);}}
中事务的实现是依赖于AOP的，当容器在创建这个 Bean 时，发现这个类中存在了被@标注的方法（修饰符为）那么就需要为这个类创建一个代理对象并放入到容器中，创建的代理对象等价于下面这个类
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();}}
上面是一段伪代码，通过、、这三个方法模拟代理类实现的逻辑。因为目标类中的saveA跟saveB方法上存在@注解，所以会对这两个方法进行拦截并嵌入事务管理的逻辑，同时方法上没有@，相当于代理类直接调用了目标类中的方法。
默认的是机制，如果方法A标注了注解@是完全没问题的，执行的时候传播给方法B，因为方法A开启了事务，线程内的的属性=false，并且执行到方法B时，事务传播依然是生效的，得到的还是方法A的，还是为false，所以事务生效；反之，如果方法A没有注解@ 时，是不受事务管理的，=true，那么传播给方法B的也为true，执行完自动提交，即使B标注了@ ；
我们会发现当通过代理类调用时整个方法的调用链如下：
实际上我们在调用saveA跟saveB时调用的是目标类中的方法，这种清空下，事务当然会失效。
3.2、在事务方法A中调用另外一个事务方法B，被调用方法B的事务没起作用
@Servicepublic class DmzService {@Transactionalpublic 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 方法实际上是由也就是目标类自己调用的，所以在 saveB 方法的前后并不会执行事务的相关操作。这也是自调用带来问题的根本原因：「自调用时，调用的是目标类中的方法而不是代理类中的方法」
3.3、自己注入自己，然后显示的调用
@Servicepublic class DmzService {// 自己注入自己@AutowiredDmzService dmzService;@Transactionalpublic 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);}
再定义一个类去实现这个接口：
@Servicepublic class OtherServiceImpl implements OtherService {@AutowiredAccountMapper mapper;@Override@Transactional(propagation=Propagation.REQUIRES_NEW)public void saveC(C c) {mapper.insert(c);}}
修改原本的实现类：
【Spring声明式与编程式事务的区别】@Servicepublic class DmzService {// 注入新建的类@AutowiredOtherService otherService;@Transactionalpublic void save(C c) {otherService.savec(c);}}
让我们再看看控制台的日志：

文章插图
可以看到是开了两个事务去执行的。
这种解决方案最简单，不需要了解其他东西，但是这种方案需要修改代码结构，本来两个方法都是属于同一个类的，现在需要强行把它们拆开。
3.4、利用

@Servicepublic class DmzService {@Transactionalpublic 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)

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

@Servicepublic class AccountSerivceImpl implements AccountService {@AutowiredAccountMapper mapper;@Transactional@Overridepublic 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)@Overridepublic void insertCodeMonkey() {Account account = new Account();account.setAccount("CodeMonkey");account.setPassword("CodeMonkey");mapper.insert(account);int a = 1 / 0;}}

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

文章插图
翻译下：不能找到当前的代理，需要设置属性为 true使其可以。
字面意思就是暴露。也就是说我们需要允许暴露代理。
我们需要在 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、：

@Servicepublic class AccountSerivceImpl implements AccountService {@AutowiredAccountMapper mapper;@AutowiredApplicationContext context;AccountService service;@PostConstructprivate void setSelf() {service = context.getBean(AccountService.class);}@Transactional@Overridepublic 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)@Overridepublic void insertCodeMonkey() {Account account = new Account();account.setAccount("CodeMonkey");account.setPassword("CodeMonkey");mapper.insert(account);int a = 1 / 0;}}

此方法不适用于
在这里，我用了一个@注解，在初始化的时候，会调用被@标记的方法(注意，仅仅是初始化的时候，才会被调用。以后都不会被调用了，大家可以打个断点试一下)，这里这么做的目的就是为了提升一下效率，不用每次都。所以如果这个类是的，就不适用这个方法了。如果是的话，就在方法中使用方法吧。
上两种方法比较方便，没有新建其他的接口或者是类，但是没有很好的封装获得Aop代理对象的过程，也不是很符合迪比特法则，也就是最少知识原则。
3.6、重写接口：
关于这个接口是做什么的，这里就不详细阐述了，简单的来说这是提供的接口，我们可以通过重写它，在初始化Bean之前或者之后，自定义一些额外的逻辑。
首先，我们需要定义一个接口：
public interface WeavingSelfProxy {void setSelfProxy(Object bean);}
要获得代理对象的类，需要去实现它：

@Servicepublic class AccountSerivceImpl implements AccountService, WeavingSelfProxy {@AutowiredAccountMapper mapper;AccountService service;@Overridepublic void setSelfProxy(Object bean) {System.out.println("进入到setSelfProxy方法");service = (AccountService) bean;}@Transactional@Overridepublic 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)@Overridepublic void insertCodeMonkey() {Account account = new Account();account.setAccount("CodeMonkey");account.setPassword("CodeMonkey");mapper.insert(account);int a = 1 / 0;}}

重写接口：

@Componentpublic class SetSelfProxyProcessor implements BeanPostProcessor {@Overridepublic Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {return bean;}@Overridepublic Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {if(bean instanceof WeavingSelfProxy){System.out.println("实现了WeavingSelfProxy接口");((WeavingSelfProxy) bean).setSelfProxy(bean);}return bean;}}

事务回滚相关问题
回滚相关的问题可以被总结为两句话
想回滚的时候事务却提交了
想提交的时候被标记成只能回滚了（ only）
先看第一种情况：「想回滚的时候事务却提交了」。这种情况往往是程序员对中事务的属性不够了解导致的。
?
默认抛出了未检查异常（继承自的异常）或者Error才回滚事务；其他异常不会触发回滚事务，已经执行的 SQL 会提交掉。如果在事务中抛出其他类型的异常，但却期望能够回滚事务，就需要指定属性。
?
对应代码其实我们上篇文章也分析过了，如下：
回滚代码
?
以上代码位于：port#方法中
?
默认情况下，只有出现或者Error才会回滚
public boolean rollbackOn(Throwable ex) {return (ex instanceof RuntimeException || ex instanceof Error);}
所以，如果你想在出现了非或者Error时也回滚，请指定回滚时的异常，例如：
@Transactional(rollbackFor = Exception.class)
第二种情况：「想提交的时候被标记成只能回滚了（ only）」。
对应的异常信息如下：
Transaction rolled back because it has been marked as rollback-only
我们先来看个例子吧

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

在上面这个例子中，的方法跟的a方法都开启了事务，并且事务的传播级别为，所以当我们在中调用的a方法时这两个方法应当是共用的一个事务。按照这种思路，虽然的a方法抛出了异常，但是我们在将异常捕获了，那么这个事务应该是可以正常提交的，为什么会抛出异常呢？
如果你看过我之前的源码分析的文章应该知道，在处理回滚时有这么一段代码
设置
在提交时又做了下面这个判断（这个方法我删掉了一些不重要的代码）
可以看到当提交时发现事务已经被标记为后会进入回滚处理中，并且传入的为 true 。在处理回滚时又有下面这段代码
抛出异常
最后在这里抛出了这个异常。
?
以上代码均位于中
?
总结起来，「主要的原因就是因为内部事务回滚时将整个大事务做了一个的标记」，所以即使我们在外部事务中 catch 了抛出的异常，整个事务仍然无法正常提交，并且如果你希望正常提交，还会抛出一个异常。
「解决方案」:
这个解决方案要依赖业务而定，你要明确你想要的结果是什么
内部事务发生异常，外部事务 catch 异常后，内部事务自行回滚，不影响外部事务
?
将内部事务的传播级别设置为 / 均可。在我们的例子中就是做如下修改：

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

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

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

?
通过显示的设置事务的状态为。这样当提交事务时会进入下面这段代码
显示回滚
最大的区别在于处理回滚时第二个参数传入的是 false, 这意味着回滚是回滚是预期之中的，所以在处理完回滚后并不会抛出异常。
读写分离跟事务结合使用时的问题
读写分离一般有两种实现方式
配置多数据源
依赖中间件，如MyCat
如果是配置了多数据源的方式实现了读写分离，那么需要注意的是：「如果开启了一个读写事务，那么必须使用写节点」，「如果是一个只读事务，那么可以使用读节点」
如果是依赖于MyCat等中间件那么需要注意：「只要开启了事务，事务内的 SQL 都会使用写节点（依赖于具体中间件的实现，也有可能会允许使用读节点，具体策略需要自行跟 DB 团队确认）」
基于上面的结论，我们在使用事务时应该更加谨慎，在没有必要开启事务时尽量不要开启。
?
一般我们会在配置文件配置某些约定的方法名字前缀开启不同的事务（或者不开启），但现在随着注解事务的流行，好多开发人员（或者架构师）搭建框架的时候在类上加上了 @ 注解，导致整个类都是开启事务的，这样严重影响数据库执行的效率，更重要的是开发人员不重视、或者不知道在查询类的方法上面自己加上 @（=.）就会导致，所有的查询方法实际并没有走从库，导致主库压力过大。
?
其次，关于如果没有对只读事务做优化的话（优化意味着将只读事务路由到读节点），那么@注解中的属性就应该要慎用。我们使用的原本目的是为了将事务标记为只读，这样当 MySQL 服务端检测到是一个只读事务后就可以做优化，少分配一些资源（例如：只读事务不需要回滚，所以不需要分配 undo log 段）。但是当配置了读写分离后，可能会可能会导致只读事务内所有的 SQL 都被路由到了主库，读写分离也就失去了意义。
参考：
@ 同一个类中无事务方法a()内部调用有事务方法b()的问题：
6种@注解的失效场景：
被标记为事务的方法互相调用的坑（上）：
被标记为事务的方法互相调用的坑（下）：
一个 @ 哪里来这么多坑：
官方都推荐使用的@事务，为啥我不建议使用！：