Spring中声明式事务存在的优缺点以及注意事项！
事务管理在系统开发中是不可缺少的⼀部分，Spring提供了很好事务管理机制，主要分为编程式事务和声明式事务两种。
关于事务的基础知识，如什么是事务，数据库事务以及Spring事务的ACID、隔离级别、传播机制、⾏为等，就不在这篇⽂章中详细介绍了。默认⼤家都有⼀定的了解。
本⽂，作者会先简单介绍下什么是声明式事务和编程式事务，再说⼀下为什么我不建议使⽤声明式事务。
编程式事务
基于底层的API，如PlatformTransactionManager、TransactionDefinition和TransactionTemplate等核⼼接⼝，开发者完全可以通过编程的⽅式来进⾏事务管理。
编程式事务⽅式需要是开发者在代码中⼿动的管理事务的开启、提交、回滚等操作。
public void test() {
TransactionDefinition def = new DefaultTransactionDefinition();
TransactionStatus status = Transaction(def);
try {
// 事务操作
// 事务提交
transactionManagermit(status);
} catch (DataAccessException e) {
// 事务提交
throw e;
}
}
  如以上代码，开发者可以通过API⾃⼰控制事务。
声明式事务
声明式事务管理⽅法允许开发者配置的帮助下来管理事务，⽽不需要依赖底层API进⾏硬编码。开发者可以只使⽤注解或基于配置的 XML 来管理事务。
@Transactional
public void test() {
// 事务操作
}
如上，使⽤@Transactional即可给test⽅法增加事务控制。
当然，上⾯的代码只是简化后的，想要使⽤事务还需要⼀些配置内容。这⾥就不详细阐述了。
这两种事务，格⼦有各⾃的优缺点，那么，各⾃有哪些适合的场景呢？为什么有⼈会拒绝使⽤声明式事务呢？
声明式事务的优点
通过上⾯的例⼦，其实我们可以很容易的看出来，声明式事务帮助我们节省了很多代码，他会⾃动帮我们进⾏事务的开启、提交以及回滚等操作，把程序员从事务管理中解放出来。
声明式事务管理使⽤了 AOP 实现的，本质就是在⽬标⽅法执⾏前后进⾏拦截。在⽬标⽅法执⾏前加⼊或创建⼀个事务，在执⾏⽅法执⾏后，根据实际情况选择提交或是回滚事务。
使⽤这种⽅式，对代码没有侵⼊性，⽅法内只需要写业务逻辑就可以了。
但是，声明式事务真的有这么好么？倒也不见得。
声明式事务的粒度问题
⾸先，声明式事务有⼀个局限，那就是他的最⼩粒度要作⽤在⽅法上。
也就是说，如果想要给⼀部分代码块增加事务的话，那就需要把这个部分代码块单独独⽴出来作为⼀个⽅法。
但是，正是因为这个粒度问题，本⼈并不建议过度的使⽤声明式事务。
⾸先，因为声明式事务是通过注解的，有些时候还可以通过配置实现，这就会导致⼀个问题，那就是这个事务有可能被开发者忽略。
事务被忽略了有什么问题呢？
⾸先，如果开发者没有注意到⼀个⽅法是被事务嵌套的，那么就可能会再⽅法中加⼊⼀些如RPC远程调⽤、消息发送、缓存更新、⽂件写⼊等操作。
我们知道，这些操作如果被包在事务中，有两个问题：
1、这些操作⾃⾝是⽆法回滚的，这就会导致数据的不⼀致。可能RPC调⽤成功了，但是本地事务回滚了，可是PRC调⽤⽆法回滚了。
2、在事务中有远程调⽤，就会拉长整个事务。那么久会导致本事务的数据库连接⼀直被占⽤，那么如果类似操作过多，就会导致数据库连接池耗尽。
有些时候，即使没有在事务中进⾏远程操作，但是有些⼈还是可能会不经意的进⾏⼀些内存操作，如运算。或者如果遇到分库分表的情况，有可能不经意间进⾏跨库操作。
但是如果是编程式事务的话，业务代码中就会清清楚楚看到什么地⽅开启事务，什么地⽅提交，什么时候回滚。这样有⼈改这段代码的时候，就会强制他考虑要加的代码是否应该⽅法事务内。
有些⼈可能会说，已经有了声明式事务，但是写代码的⼈没注意，这能怪谁。
话虽然是这么说，但是我们还是希望可以通过⼀些机制或者规范，降低这些问题发⽣的概率。
⽐如建议⼤家使⽤编程式事务，⽽不是声明式事务。因为，作者⼯作这么多年来，发⽣过不⽌⼀次开发者没注意到声明式事务⽽导致的故障。
因为有些时候，声明式事务确实不够明显。
spring aop应用场景声明式事务⽤不对容易失效
除了事务的粒度问题，还有⼀个问题那就是声明式事务虽然看上去帮我们简化了很多代码，但是⼀旦没⽤对，也很容易导致事务失效。
如以下⼏种场景就可能导致声明式事务失效：
1、@Transactional 应⽤在⾮ public 修饰的⽅法上
2、@Transactional 注解属性 propagation 设置错误
3、@Transactional 注解属性 rollbackFor 设置错误
4、同⼀个类中⽅法调⽤，导致@Transactional失效
5、异常被catch捕获导致@Transactional失效
6、数据库引擎不⽀持事务
以上⼏个问题，如果使⽤编程式事务的话，很多都是可以避免的。
使⽤声明事务失效的问题我们发⽣过很多次。不知道⼤家有没有遇到过，我是实际遇到过的
因为Spring的事务是基于AOP实现的，但是在代码中，有时候我们会有很多切⾯，不同的切⾯可能会来处理不同的事情，多个切⾯之间可能会有相互影响。
在之前的⼀个项⽬中，我就发现我们的Service层的事务全都失效了，⼀个SQL执⾏失败后并没有回滚，排查下来才发现，是因为⼀位同事新增了⼀个切⾯，这个切⾯⾥⾯做个异常的统⼀捕获，导致事务的切⾯没有捕获到异常，导致事务⽆法回滚。
这样的问题，发⽣过不⽌⼀次，⽽且不容易被发现。
很多⼈还是会说，说到底还是⾃⼰能⼒不⾏，对事务理解不透彻，⽤错了能怪谁。
但是我还是那句话，我们确实⽆法保证所有⼈的能⼒都很⾼，也⽆法要求所有开发者都能不出错。我们能做的就是，尽量可以通过机制或者规范，来避免或者降低这些问题发⽣的概率。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。