Spring事务管理之几种方式实现事务
转载自:https://blog.csdn.net/chinacr07/article/details/78817449
Spring的事务管理机制实现的原理,就是通过这样一个动态代理对所有需要事务管理的Bean进行加载,并根据配置在invoke方法中对当前调用的 方法名进行判定,并在method.invoke方法前后为其加上合适的事务管理代码,这样就实现了Spring式的事务管理。Spring中的AOP实 现更为复杂和灵活,不过基本原理是一致的。
1、事务认识
大家所了解的事务Transaction,它是一些列严密操作动作,要么都操作完成,要么都回滚撤销。Spring事务管理基于底层数据库本身的事务处理机制。数据库事务的基础,是掌握Spring事务管理的基础。这篇总结下Spring事务。
事务具备ACID四种特性,ACID是Atomic(原子性)、Consistency(一致性)、Isolation(隔离性)和Durability(持久性)的英文缩写。
(1)原子性(Atomicity)
事务最基本的操作单元,要么全部成功,要么全部失败,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚到事务开始前的状态,就像这个事务从来没有执行过一样。
(2)一致性(Consistency)
事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成,那么系统中所有变化将正确地应用,系统处于有效状态。如果在事务中出现错误,那么系统中的所有变化将自动地回滚,系统返回到原始状态。
(3)隔离性(Isolation)
指的是在并发环境中,当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时,数据所处的状态要么是另一事务修改它之前的状态,要么是另一事务修改它之后的状态,事务不会查看到中间状态的数据。
(4)持久性(Durability)
指的是只要事务成功结束,它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃,重新启动数据库系统后,数据库还能恢复到事务成功结束时的状态。
2、事务的传播特性
事务传播行为就是多个事务方法调用时,如何定义方法间事务的传播。Spring定义了7中传播行为:
(1)propagation_requierd:如果当前没有事务,就新建一个事务,如果已存在一个事务中,加入到这个事务中,这是Spring默认的选择。
(2)propagation_supports:支持当前事务,如果没有当前事务,就以非事务方法执行。
(3)propagation_mandatory:使用当前事务,如果没有当前事务,就抛出异常。
(4)propagation_required_new:新建事务,如果当前存在事务,把当前事务挂起。
(5)propagation_not_supported:以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
(6)propagation_never:以非事务方式执行操作,如果当前事务存在则抛出异常。
(7)propagation_nested:如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与propagation_required类似的操作。
3、事务的隔离级别
(1)read uncommited:是最低的事务隔离级别,它允许另外一个事务可以看到这个事务未提交的数据。
(2)read commited:保证一个事物提交后才能被另外一个事务读取。另外一个事务不能读取该事物未提交的数据。
(3)repeatable read:这种事务隔离级别可以防止脏读,不可重复读。但是可能会出现幻象读。它除了保证一个事务不能被另外一个事务读取未提交的数据之外还避免了以下情况产生(不可重复读)。
(4)serializable:这是花费最高代价但最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读,不可重复读之外,还避免了幻象读
(5)脏读、不可重复读、幻象读概念说明:
a.脏读:指当一个事务正字访问数据,并且对数据进行了修改,而这种数据还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。
b.不可重复读:指在一个事务内,多次读同一数据。在这个事务还没有执行结束,另外一个事务也访问该同一数据,那么在第一个事务中的两次读取数据之间,由于第二个事务的修改第一个事务两次读到的数据可能是不一样的,这样就发生了在一个事物内两次连续读到的数据是不一样的,这种情况被称为是不可重复读。
c.幻象读:一个事务先后读取一个范围的记录,但两次读取的纪录数不同,我们称之为幻象读(两次执行同一条 select 语句会出现不同的结果,第二次读会增加一数据行,并没有说这两次执行是在同一个事务中)
4、事务几种实现方式
(1)编程式事务管理对基于 POJO 的应用来说是唯一选择。根据PlatformTransactionManager、TransactionDefinition 和 TransactionStatus 三个核心接口,我们就可以实现通过编程式进行事务管理;
我们需要在代码中调用beginTransaction()、commit()、rollback()等事务管理相关的方法,这就是编程式事务管理。
缺点: 代码需要嵌入到业务代码里面。影响代码量
声明式事务管理
(2)配置文件:基于 TransactionProxyFactoryBean的声明式事务管理
(3)通过注解:基于 @Transactional 的声明式事务管理 方便、但是要指定所有与数据库交互的连接点
(4)配置文件:基于Aspectj AOP配置事务 可以指定所需要进行事务控制的连接点
后3种方式的实现可以查看原帖: https://blog.csdn.net/chinacr07/java/article/details/78817449
5、事务不生效场景
转载自:https://mrbird.cc/Spring%E5%A3%B0%E6%98%8E%E5%BC%8F%E4%BA%8B%E5%8A%A1%E5%8E%9F%E7%90%86.html
对Spring事务机制不熟悉的coder经常会遇到事务不生效的场景,这里列举两个最为常见的场景,并给出对应的解决方案。
场景一:Service方法抛出的异常不是RuntimeException或者Error类型,并且@Transactional注解上没有指定回滚异常类型。
对应的代码例子为:
@Service public class UserServiceImpl implements UserService { private final UserMapper userMapper; public UserServiceImpl(UserMapper userMapper) { this.userMapper = userMapper; } @Transactional @Override public void saveUser(User user) throws Exception { userMapper.save(user); // 测试事务回滚 if (!StringUtils.hasText(user.getUsername())) { throw new Exception("username不能为空"); } } }
默认情况下,Spring事务只对RuntimeException或者Error类型异常(错误)进行回滚,检查异常(通常为业务类异常)不会导致事务回滚。。
所以要解决上面这个事务不生效的问题,我们主要有以下两种方式:
-
手动在@Transactional注解上声明回滚的异常类型(方法抛出该异常及其所有子类型异常都能触发事务回滚)
@Service public class UserServiceImpl implements UserService { private final UserMapper userMapper; public UserServiceImpl(UserMapper userMapper) { this.userMapper = userMapper; } @Transactional(rollbackFor = Exception.class) @Override public void saveUser(User user) throws Exception { userMapper.save(user); // 测试事务回滚 if (!StringUtils.hasText(user.getUsername())) { throw new Exception("username不能为空"); } } }
2. 方法内手动抛出的检查异常类型改为RuntimeException子类型:
定义一个自定义异常类型ParamInvalidException:
public class ParamInvalidException extends RuntimeException{ public ParamInvalidException(String message) { super(message); } }
修改UserServiceImpl的saveUser方法:
@Service public class UserServiceImpl implements UserService { private final UserMapper userMapper; public UserServiceImpl(UserMapper userMapper) { this.userMapper = userMapper; } @Transactional @Override public void saveUser(User user) { userMapper.save(user); // 测试事务回滚 if (!StringUtils.hasText(user.getUsername())) { throw new ParamInvalidException("username不能为空"); } } }
场景二、非事务方法直接通过this调用本类事务方法。这种情况也是比较常见的,举个例子,修改UserServiceImpl:
@Service public class UserServiceImpl implements UserService { private final UserMapper userMapper; public UserServiceImpl(UserMapper userMapper) { this.userMapper = userMapper; } @Override public void saveUserTest(User user) { this.saveUser(user); } @Transactional @Override public void saveUser(User user) { userMapper.save(user); // 测试事务回滚 if (!StringUtils.hasText(user.getUsername())) { throw new ParamInvalidException("username不能为空"); } } }
在UserServiceImpl中,我们新增了saveUserTest方法,该方法没有使用@Transactional注解标注,为非事务方法,内部直接调用了saveUser事务方法。
这种情况下事务失效的原因为:Spring事务控制使用AOP代理实现,通过对目标对象的代理来增强目标方法。而上面例子直接通过this调用本类的方法的时候,this的指向并非代理类,而是该类本身。
解决办法:
这种情况下要让事务生效主要有如下两种解决方式(原理都是使用代理对象来替代this):
方式一:从IOC容器中获取UserService Bean,然后调用它的saveUser方法
@Service public class UserServiceImpl implements UserService, ApplicationContextAware { private final UserMapper userMapper; private ApplicationContext context; public UserServiceImpl(UserMapper userMapper) { this.userMapper = userMapper; } @Override public void saveUserTest(User user) { UserService userService = context.getBean(UserService.class); userService.saveUser(user); } @Transactional @Override public void saveUser(User user) { userMapper.save(user); // 测试事务回滚 if (!StringUtils.hasText(user.getUsername())) { throw new ParamInvalidException("username不能为空"); } } @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.context = applicationContext; } }
上面代码我们通过实现ApplicationContextAware接口注入了应用上下文ApplicationContext,然后从中取出UserService Bean来代替this。
方式二:从AOP上下文中取出当前代理对象:
不累述,有兴趣去原本看看