Spring事务处理方式
方式1：注解式事务
- 使用@Transactional注解完成事务控制，此注解可添加到类上，则对类中所有方法执行事务的设定，注解添加到方法上，则对该方法执行事务处理
- @Transactional(...)注解参数说明：
- propagation = Propagation.REQUIRED：设置事务的传播特性，例如当多个事务叠加时，谁起主导作用等
- noRollbackForClassName = "异常名称"：指定发生什么异常不回滚，使用的是异常的名称
- noRollbackFor = 异常.class：指定发生什么异常不回滚，使用的是异常的类型
- rollbackForClassName = "异常名称"：指定发生什么异常必须回滚，使用的是异常的名称
- rollbackFor = 异常.class：指定发生什么异常必须回滚，使用的是异常的类型：
- timeout = -1：连接超时设置，默认值是-1,表示永不超时
- readOnly = false：默认为false，如果是查询操作，必须设置为true
- isolation = Isolation.DEFAULT：使用的数据库的默认隔离级别
- 注意：当一个类中有较多方法时，对方法进行一对一的注解式事务管理太多繁琐，简单演示事务特性时可以使用注解式事务，在实际项目中不常用
方式2：声明式事务
- 在配置文件中添加一次，整个项目遵循该事务的设定，是Spring常用的，也是非常有名的事务处理方式
- 要求项目中的方法命名有规范，例如：
- 添加操作方法名包含：add，save，insert，set等单词
- 更新操作方法名包含：update，change，modify等单词
- 删除操作方法名包含：delete，drop，remove，clear等单词
- 查询操作方法名包含：select，find，search，get等单词
- 上述规范的原因：为了配置事务切面时，可以使用通配符来匹配满足通配条件的方法
声明式事务案例
applicationContext_trans.xml
- 在src/main/resources目录下新建applicationContext_trans.xml，注意：这里如果使用idea默认的xml头信息，< tx >标签的属性显示不出来，可以使用下面的头信息
业务实现类
- 修改UserServiceImpl：持有Account业务逻辑层的接口类型的变量，在User业务逻辑中嵌套调用Account业务
package com.example.service.impl;
import com.example.mapper.UserMapper;
import com.example.pojo.Account;
import com.example.pojo.User;
import com.example.service.AccountService;
import com.example.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
/**
* 业务实现类
*/
@Service
public class UserServiceImpl implements UserService {
//业务逻辑层实现类持有数据访问层的接口类型的变量
@Autowired
UserMapper userMapper;
//持有Account业务逻辑层的接口类型的变量
@Autowired
AccountService accountService;
@Override
public int insert(User user) {
int num = userMapper.insert(user);
if(num == 1){
System.out.println("用户导入成功!");
}else{
System.out.println("用户导入失败!");
}
//嵌套调用账户的业务逻辑功能
accountService.save(new Account(25, "荷包蛋6","富婆的账户6"));
return num;
}
}
测试
package com.example.test;
import com.example.pojo.User;
import com.example.service.UserService;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class TestUserAndAccount {
@Test
public void testUserAndAccount(){
//创建Spring容器
ApplicationContext ac = new ClassPathXmlApplicationContext("applicationContext_trans.xml");
//获取用户的业务逻辑层对象
UserService userService = (UserService) ac.getBean("userServiceImpl");
//调用业务功能
userService.insert(new User(2, "荷包蛋2", "hanzhanghan2"));
}
}
测试输出
- 从控制台看出两个业务的sql语句都执行成功，程序在出错后终止
- 在上述事务配置下，用户业务和账户业务都被添加事务，从用户表和账户表可以看出，在内部嵌套的业务执行失败后，两个事务都被撤销，两条记录都未成功导入
修改aplicationContext_trans.xml
- 对下述两个标签添加新的标签属性，对于某些指定异常不回滚
测试输出
- 这时对于算术异常不进行事务回滚，再次测试，两条记录成功导入数据表并有效保存
注意
如果当声明式注解所规划的事务管理和某个业务层的业务方法对事务的个性化需求相冲突时，可以再另外开启注解式事务并设置两种事务的优先级，达到优先使用注解式事务的目的。当order属性的值越大，事务的优先级越高
- 在applicationContext_trans.xml中增加注解式事务驱动并设置事务优先级
- 为applicationContext_trans.xml中的< aop:advisor / >标签设置事务级别，此时如果某业务逻辑层的业务方法使用了注解式事务，则该业务方法的事务遵循注解式事务
Spring事务的传播特性
- 多个事务之间的合并，互斥等都可以通过设置事务的传播特性来解决
- 常用特性：
- PROPAGATION_REQUIRED：必被包含事务(增删改必用)
- PROPAGATION_REQUIRES_NEW：自己开启新事务，不管之前是否有事务
- PROPAGATION_SUPPORTS：支持事务，如果加入的方法有事务，则遵循该事务，如果没有，不单开事务
- PROPAGATION_NEVER：不能运行在事务中，如果被包在事务中，抛异常
- PROPAGATION_NOT_SUPPORTED：不支持事务，运行在非事务环境中
- 不常用特性：
- PROPAGATION_MANDATORY：必须包在事务中，没有事务则抛出异常
- PROPAGATION_NESTED：嵌套事务
- 注意：
- 事务必须声明在业务逻辑层
- 事务传播特性的部分组合结果：下表列出了在User业务实现类中嵌套调用Account业务实现类，当内外层出现不同事务特性组合时，是分别能对users表和accounts表起到数据修改作用还是被事务回滚
Spring事务的隔离原则
- 未提交读：允许脏读，可能读到其他会话中未提交事务所修改的数据，例如，读取数据后，发生数据回滚，则前面读到的数据就是脏读，读取到了未真实提交的数据
- 提交读：只能读取到已经提交的数据。oracle等多数数据库默认都是该级别，即读已提交(不重复读)
- 可重复读：在同一个事务内的查询都是与事务开始时刻一致，是InnoDB数据库引擎的默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是存在幻象读，但InnoDB解决了幻读
- 串行读：完全串行化的读，每次读都需要获取表级共享锁，读写相互都会阻塞
- 注意：mysql默认事务处理级别为：可重复读。oracel支持读已提交和串行读两种隔离级别，但是其默认事务隔离级别是：读已提交
添加事务管理器的原因
- 不同技术对事务提交和回滚的实现简单列举如下，可见不同的技术使用的数据库操作对象不同
- JDBC：Connection con.commit(); con.rollback();
- MyBatis：SqlSession sqlSession.commit(); sqlSession.rollback();
- Hibernate：Session session.commit(); session.rollback();
- 使用事务管理器，目的就是为了生成相应技术下的数据库连接 + 执行语句的对象
- 如果使用MyBatis框架，必须使用DataSourceTransactionManager类完成处理