🌟个人主页:时间会证明一切.
目录
- Spring中如何开启事务?
- 编程式事务
- 声明式事务
- 声明式事务的优点
- 声明式事务的粒度问题
- 声明式事务用不对容易失效
- Spring的事务传播机制有哪些?
- Spring事务失效可能是哪些原因?
- 代理失效的情况
- @Transactional用的不对
- 异常被捕获
- 事务中用了多线程
- 数据库引擎不支持事务
Spring中如何开启事务?
事务管理在系统开发中是不可缺少的一部分,Spring提供了很好事务管理机制,主要分为编程式事务和声明式事务两种。
编程式事务
基于底层的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;
}
}
当然,我们也可以使用Spring中提供的TransactionTemplate来实现编程式事务。
@Autowired
protected TransactionTemplate transactionTemplate;
public void test(){
return transactionTemplate.execute(transactionStatus -> {
//事务操作
});
}
public void test1(){
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
@Override
protected void doInTransactionWithoutResult(TransactionStatus transactionStatus) {
}
});
}
如以上代码,开发者可以通过API自己控制事务。
声明式事务
声明式事务管理方法允许开发者配置的帮助下来管理事务,而不需要依赖底层API进行硬编码。开发者可以只使用注解或基于配置的 XML 来管理事务。
@Transactional
public void test() {
// 事务操作
}
如上,使用@Transactional即可给test方法增加事务控制。
声明式事务的优点
通过上面的例子,其实我们可以很容易的看出来,声明式事务帮助我们节省了很多代码,他会自动帮我们进行事务的开启、提交以及回滚等操作,把程序员从事务管理中解放出来。
声明式事务管理使用了 AOP 实现的,本质就是在目标方法执行前后进行拦截。在目标方法执行前加入或创建一个事务,在执行方法执行后,根据实际情况选择提交或是回滚事务。
使用这种方式,对代码没有侵入性,方法内只需要写业务逻辑就可以了。
但是,声明式事务真的有这么好么?倒也不见得。
声明式事务的粒度问题
首先,声明式事务有一个局限,那就是他的最小粒度要作用在方法上。
也就是说,如果想要给一部分代码块增加事务的话,那就需要把这个部分代码块单独独立出来作为一个方法。
但是,正是因为这个粒度问题,本人并不建议过度的使用声明式事务。
首先,因为声明式事务是通过注解的,有些时候还可以通过配置实现,这就会导致一个问题,那就是这个事务有可能被开发者忽略。
事务被忽略了有什么问题呢?
首先,如果开发者没有注意到一个方法是被事务嵌套的,那么就可能会再方法中加入一些如RPC远程调用、消息发送、缓存更新、文件写入等操作。
我们知道,这些操作如果被包在事务中,有两个问题:
1、这些操作自身是无法回滚的,这就会导致数据的不一致。可能RPC调用成功了,但是本地事务回滚了,可是RPC调用无法回滚了。
2、在事务中有远程调用,就会拉长整个事务。那么就会导致本事务的数据库连接一直被占用,那么如果类似操作过多,就会导致数据库连接池耗尽。
有些时候,即使没有在事务中进行远程操作,但是有些人还是可能会不经意的进行一些内存操作,如运算。或者如果遇到分库分表的情况,有可能不经意间进行跨库操作。
但是如果是编程式事务的话,业务代码中就会清清楚楚看到什么地方开启事务,什么地方提交,什么时候回滚。这样有人改这段代码的时候,就会强制他考虑要加的代码是否应该方法事务内。
有些人可能会说,已经有了声明式事务,但是写代码的人没注意,这能怪谁。
话虽然是这么说,但是我们还是希望可以通过一些机制或者规范,降低这些问题发生的概率。
比如建议大家使用编程式事务,而不是声明式事务。因为,作者工作这么多年来,发生过不止一次开发者没注意到声明式事务而导致的故障。
因为有些时候,声明式事务确实不够明显。
声明式事务用不对容易失效
除了事务的粒度问题,还有一个问题那就是声明式事务虽然看上去帮我们简化了很多代码,但是一旦没用对,也很容易导致事务失效。
如以下几种场景就可能导致声明式事务失效:
1、@Transactional 应用在非 public 修饰的方法上
2、@Transactional 注解属性 propagation 设置错误
3、@Transactional 注解属性 rollbackFor 设置错误
4、同一个类中方法调用,导致@Transactional失效
5、异常被catch捕获导致@Transactional失效
6、数据库引擎不支持事务
以上几个问题,如果使用编程式事务的话,很多都是可以避免的。
使用声明事务失效的问题我们发生过很多次。不知道大家有没有遇到过,我是实际遇到过的
因为Spring的事务是基于AOP实现的,但是在代码中,有时候我们会有很多切面,不同的切面可能会来处理不同的事情,多个切面之间可能会有相互影响。
在之前的一个项目中,我就发现我们的Service层的事务全都失效了,一个SQL执行失败后并没有回滚,排查下来才发现,是因为一位同事新增了一个切面,这个切面里面做个异常的统一捕获,导致事务的切面没有捕获到异常,导致事务无法回滚。
后来解决的方式可以设置切面的执行顺序,比如使用@Order或者实现Ordered接口等,但是我们这里没这么做,而是经过代码分析后把异常捕获的这部分移除了,异常抛给上游再处理。
之所以没有通过设置顺序解决,主要是因为这玩意不好控制,完以后面新增了别的注解之类的还得再改动,所以经过分析之后这里异常捕获并非必要,就这么改了。
这样的问题,发生过不止一次,而且不容易被发现。
很多人还是会说,说到底还是自己能力不行,对事务理解不透彻,用错了能怪谁。
Spring的事务传播机制有哪些?
Spring的事务传播机制用于控制在多个事务方法相互调用时事务的行为。
在复杂的业务场景中,多个事务方法之间的调用可能会导致事务的不一致,如出现数据丢失、重复提交等问题,使用事务传播机制可以避免这些问题的发生,保证事务的一致性和完整性。
Spring的事务规定了7种事务的传播级别,默认的传播机制是REQUIRED
- REQUIRED,如果不存在事务则开启一个事务,如果存在事务则加入之前的事务,总是只有一个事务在执行
- REQUIRES_NEW,每次执行新开一个事务,如果当前存在事务,则把当前事务挂起
- SUPPORTS,有事务则加入事务,没有事务则普通执行
- NOT_SUPPORTED,有事务则暂停该事务,没有则普通执行
- MANDATORY,强制有事务,没有事务则报异常
- NEVER,有事务则报异常
- NESTED,如果之前有事务,则创建嵌套事务,嵌套事务回滚不影响父事务,反之父事务影响嵌套事务
Spring事务失效可能是哪些原因?
Spring中比较容易失效的就是通过@Transactional 定义的声明式事务,他在以下几个场景中会导致事务失效,首先,就是Spring的@Transactional是基于Spring的AOP机制实现的,而AOP机制又是基于动态代理实现的。那么如果代理失效了,事务也就会失效。
代理失效的情况
在上面这篇中介绍过几种代理失效的情况,主要就是分为类的内部调用、final方法、static方法等。
所以就是以下几种情况就会失效:
1、@Transactional 应用在非 public 修饰的方法上
public class MyService {
@Transactional
private void doInternal() {
System.out.println("Doing internal work...");
}
}
private方法,只会在当前对象中的其他方法中调用,也就是会进行对象的自调用,这种情况是用this调用的,并不会走到代理对象,而@Transactional是基于动态代理实现的,所以代理会失效。
2、同一个类中方法调用,导致@Transactional失效
public class MyService {
public void doSomething() {
doInternal(); // 自调用方法
}
@Transactional
public void doInternal() {
System.out.println("Doing internal work...");
}
}
以上,和private是一回事,因为没办法走到代理服务,所以事务会失效。
3、final、static方法
由于AOP是通过创建代理对象来实现的,而无法对final方法进行子类化和覆盖,所以无法拦截这些方法。
还有就是调用static方法,因为这类方法是属于这个类的,并不是对象的,所以无法被AOP。
@Transactional用的不对
1、@Transactional 注解属性 propagation 设置错误
@Service
public class ExampleService {
@Autowired
private ExampleRepository repository;
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void methodA() {
repository.someDatabaseOperation();
}
public void methodB() {
repository.anotherDatabaseOperation();
}
}
@Service
public class SomeService {
@Autowired
private ExampleService exampleService;
@Transactional
public void doSomething() {
// 这里执行一些业务逻辑
exampleService.methodA(); // 这个方法由于 NOT_SUPPORTED 属性,会在非事务下执行
exampleService.methodB();
// ...
}
}
以上,如果事务发生回滚,则methodA并不会回滚。因为他的propagation事不支持事务,那么他就不会一起回滚。
2、@Transactional 注解属性 rollbackFor 设置错误
public class MyService {
@Transactional(rollbackFor = RuntimeException.class)
private void doInternal() {
System.out.println("Doing internal work...");
}
}
以上,如果发生非RuntimeException,则事务不会回滚,那么就会导致事务失效。所以需要指定为(rollbackFor = Exception.class)
3、用错注解
有的时候,你排查了很久,发现都没问题,但是还是不生效,然后找别人来帮你看,他上来就看了一下你用的@Transactional,发现并不是Spring中的,而是其他什么地方的,比如 javax.transaction.Transactional ,这样也会导致事务失效。
异常被捕获
5、异常被catch捕获导致@Transactional失效
public class MyService {
@Transactional
public void doSomething() {
try{
doInternal();
}catch(Exception e){
logger.error(e);
}
}
}
因为异常被捕获,所以就没办法基于异常进行rollback了,所以事务会失效。
事务中用了多线程
@Transactional 的事务管理使用的是 ThreadLocal 机制来存储事务上下文,而** ThreadLocal 变量是线程隔离的**,即每个线程都有自己的事务上下文副本。因此,在多线程环境下,Spring 的声明式事务会失效,即新线程中的操作不会被包含在原有的事务中。
数据库引擎不支持事务
这个好理解,如myisam,不支持的肯定就不行了。