Spring5【八】Spring 的声明式事务
13、声明式事务
13.1 事务
- 把一组业务当成一个业务来做,要么同时成功,要么同时失败
- 事务在项目的开发中十分重要,涉及到数据的一致性问题
- 确保完整性和一致性
事务四个属性 ACID
-
原子性(atomicity)
- 事务是原子性操作,由一系列动作组成,事务的原子性确保动作要么全部完成,要么完全不起作用
-
一致性(consistency)
- 一旦所有事务动作完成,事务就要被提交。数据和资源处于一种满足业务规则的一致性状态中
-
隔离性(isolation)
- 可能多个事务会同时处理相同的数据,因此每个事务都应该与其他事务隔离开来,防止数据损坏
-
持久性(durability)
- 事务一旦提交,无论系统发生什么问题,结果都不会再被影响,被持久化的写到存储器中
13.2 Spring 中的事务管理
Spring 在不同的事务管理 API 之上定义了一个抽象层,使得开发人员不必了解底层的事务管理 API 就可以使用 Spring 的事务管理机制。Spring 支持编程式事务管理和声明式的事务管理。
声明式事务:利用 AOP
- 一般情况下比编程式事务好用。
- 将事务管理代码从业务方法中分离出来,以声明的方式来实现事务管理。
- 将事务管理作为横切关注点,通过 AOP 方法模块化。Spring 中通过 Spring AOP 框架支持声明式事务管理。
编程式事务:需要在代码中进行事务的管理
- 将事务管理代码嵌到业务方法中来控制事务的提交和回滚
- 缺点:必须在每个事务操作业务逻辑中包含额外的事务管理代码
为什么需要事务:
-
如果不配置事务,可能存在数据提交不一致的情况
-
如果不在 spring 中去配置事务,就需要在代码中手动配置事务
声明式事务:利用 AOP
测试:
-
基于之前的案例,给 userDao 接口新增两个方法,删除和增加用户
public interface UserMapper { public List<User> selectUser(); //添加一个用户 public int addUser(User user); //删除一个用户 public int deleteUser(int id); }
-
mapper.xml 文件,故意把 delete 写错为 deletes
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.song.mapper.UserMapper"> <select id="selectUser" resultType="user"> select * from mybatis.user </select> <insert id="addUser" parameterType="user"> insert into user (id, name, pwd) values (#{id},#{name},#{pwd}); </insert> <delete id="deleteUser" parameterType="_int"> <!--deletes from user where id=#{id}--> delete from user where id=#{id} </delete> </mapper>
-
编写接口的实现类,在实现类中,进行调用操作
public class UserMapperImpl extends SqlSessionDaoSupport implements UserMapper { public List<User> selectUser() { User user = new User(5, "小王", "123456"); UserMapper mapper = getSqlSession().getMapper(UserMapper.class); mapper.addUser(user); mapper.deleteUser(5); return mapper.selectUser(); } public int addUser(User user) { return getSqlSession().getMapper(UserMapper.class).addUser(user); } public int deleteUser(int id) { return getSqlSession().getMapper(UserMapper.class).deleteUser(id); } }
-
测试
@Test public void test(){ ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); UserMapper userMapper = context.getBean("userMapper", UserMapper.class); List<User> users = userMapper.selectUser(); for (User u : users){ System.out.println(u); } }
-
测试结果
报错:sql 异常, delete 写错
结果:插入成功
说明没有进行事务的管理,我们想让他们都成功才成功,有一个失败,就都失败,我们就应该需要事务!
以前我们都需要自己手动管理事务,十分麻烦,但是 Spring 给我们提供了事务管理,我们只需要配置即可。
Spring 进行事务的管理
一个使用 MyBatis-Spring 的其中一个主要原因是它允许 MyBatis 参与到 Spring 的事务管理中。而不是给 MyBatis 创建一个新的专用事务管理器,MyBatis-Spring 借助了 Spring 中的 DataSourceTransactionManager 来实现事务管理。
事务管理器:
- 无论使用Spring的哪种事务管理策略(编程式或者声明式)事务管理器都是必须的。
- 就是 Spring的核心事务管理抽象,管理封装了一组独立于技术的方法。
-
使用 Spring 管理事务,注意头文件的约束导入 : tx
xmlns:tx="http://www.springframework.org/schema/tx" http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd">
-
配置声明式事务即事务管理器,这里配置的是 JDBC 事务
<!--配置声明式事务--> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean>
-
配置事务的通知和事务的切入(AOP)
注意:使用 AOP 需要导入 AOP 的约束头文件
<!--结合AOP,实现事务的织入--> <!--配置事务通知--> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <!--给哪些方法配置事务--> <!--配置事务的传播特性 propagation--> <tx:attributes> <tx:method name="add" propagation="REQUIRED"/> <tx:method name="delete" propagation="REQUIRED"/> <tx:method name="update" propagation="REQUIRED"/> <tx:method name="query" read-only="true"/> <tx:method name="*" propagation="REQUIRED"/> </tx:attributes> </tx:advice> <!--配置事务切入--> <aop:config> <aop:pointcut id="txPointCut" expression="execution(* com.song.mapper.*.*(..))"/> <aop:advisor advice-ref="txAdvice" pointcut-ref="txPointCut"/> </aop:config>
-
测试(其他代码不用改动)
结果:数据库中的数据没有变动
说明说明事务管理已经成功。
注意:
spring 事务传播特性,即 <tx:method/> 中的 propagation 属性:事务传播行为就是多个事务方法相互调用时,事务如何在这些方法间传播。
Spring 支持 7 种事务传播行为:
- propagation_requierd:如果当前没有事务,就新建一个事务,如果已存在一个事务中,加入到这个事务中,这是最常见的选择。
- propagation_supports:支持当前事务,如果没有当前事务,就以非事务方法执行。
- propagation_mandatory:使用当前事务,如果没有当前事务,就抛出异常。
- propagation_required_new:新建事务,如果当前存在事务,把当前事务挂起。
- propagation_not_supported:以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
- propagation_never:以非事务方式执行操作,如果当前事务存在则抛出异常。
- propagation_nested:如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与propagation_required类似的操作
Spring 默认的事务传播行为是 PROPAGATION_REQUIRED,它适合于绝大多数的情况。
假设 ServiveX#methodX() 都工作在事务环境下(即都被 Spring 事务增强了),假设程序中存在如下的调用链:Service1#method1()->Service2#method2()->Service3#method3(),那么这 3 个服务类的 3 个方法通过 Spring 的事务传播机制都工作在同一个事务中。
比如,上面案例的几个方法存在调用,所以会被放在一组事务当中。