事务的概论
为什么需要事务?
将⼀组操作封装成⼀个执⾏单元(封装到⼀起),要么全部成功,要么全部失败。
Spring 中的事务操作分为两类:
- 编程式事务(⼿动写代码操作事务)。
- 声明式事务(利⽤注解⾃动开启和提交事务)
事务在mysql中有体现:
- 开启事务:start transaction;
- 提交事务:commit;
- 回滚事务:rollback;
事务有4 ⼤特性(ACID),原⼦性、持久性、⼀致性和隔离性。
事务隔离级别
-
原⼦性:⼀个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执⾏过程中发⽣错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执⾏过⼀样。
-
⼀致性:在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写⼊的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以⾃发性地完成预定的⼯作。
-
持久性:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
-
隔离性:数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒,隔离性可以防⽌多个事务并发执⾏时由于交叉执⾏⽽导致数据的不⼀致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串⾏化(Serializable)
- READ UNCOMMITTED(读未提交):读未提交,也叫未提交读,该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据,⽽未提交的数据可能会发⽣回滚,因此我们把该级别读取到的数据称之为脏数据,把这个问题称之为脏读。
- READ COMMITTED:读已提交,也叫提交读,该隔离级别的事务能读取到已经提交事务的数据,因此它不会有脏读问题。但由于在事务的执⾏中可以读取到其他事务提交的结果,所以在不同时间的相同 SQL 查询中,可能会得到不同的结果,这种现象叫做不可重复读。
- REPEATABLE READ:可重复读,是 MySQL 的默认事务隔离级别,它能确保同⼀事务多次查询的结果⼀致。但也会有新的问题,⽐如此级别的事务正在执⾏时,另⼀个事务成功的插⼊了某条数据,但因为它每次查询的结果都是⼀样的,所以会导致查询不到这条数据,⾃⼰重复插⼊时⼜失败(因为唯⼀约束的原因)。明明在事务中查询不到这条信息,但⾃⼰就是插⼊不进去,这就叫幻读(Phantom Read)
- SERIALIZABLE:序列化,事务最⾼隔离级别,它会强制事务排序,使之不会发⽣冲突,从⽽解决了脏读、不可重复读和幻读问题,但因为执⾏效率低,所以真正使⽤的场景并不多
● 脏读:⼀个事务读取到了另⼀个事务修改的数据之后,后⼀个事务⼜进⾏了回滚操作,从⽽导致第⼀个事务读取的数据是错误的。
● 不可重复读:⼀个事务两次查询得到的结果不同,因为在两次查询中间,有另⼀个事务把数据修改了。
● 幻读:⼀个事务两次查询中得到的结果集不同,因为在两次查询中另⼀个事务有新增了⼀部分数据
Mysql 有没有解决幻读问题?有解决但是并未全部解决
RR级别(可重复读)+MVCC(多版本管理机制)—》解决幻读问题。
读有两种:
- 当前读:没有缓存及时进行读操作----》MVCC + 锁 解决幻读
- 幻象读(快照读):有缓存记录当前的操作,然后执行缓存的操作—》使用MVCC解决幻读
彻底解决:1.串行化,2.MVCC + 锁
Spring 的事务隔离级别(五种)
这里的设置的事务级别是以Spring为主
- Isolation.DEFAULT:以连接的数据库的事务隔离级别为主。
- Isolation.READ_UNCOMMITTED:读未提交,可以读取到未提交的事务,存在脏读。
- Isolation.READ_COMMITTED:读已提交,只能读取到已经提交的事务,解决了脏读,存在不可重复读。
- Isolation.REPEATABLE_READ:可重复读,解决了不可重复读,但存在幻读(MySQL默认级别)。
- Isolation.SERIALIZABLE:串⾏化,可以解决所有并发问题,但性能太低。
编程式事务
同样的对于Spring来说。编程事务也是这些操作SpringBoot 内置了两个对象,DataSourceTransactionManager ⽤来获取事务(开启事务)、提交或回滚事务的,⽽ TransactionDefinition 是事务的属性,在获取事务的时候需要将TransactionDefinition 传递进去从⽽获得⼀个事务TransactionStatus,
@RestController
public class UserController {
@Resource
private UserService userService;
// JDBC 事务管理器
@Resource
private DataSourceTransactionManager dataSourceTransactionManager;
// 定义事务属性
@Resource
private TransactionDefinition transactionDefinition;
@RequestMapping("/sava")
public Object save(User user) {
// 开启事务
TransactionStatus transactionStatus = dataSourceTransactionManager
.getTransaction(transactionDefinition);
// 插⼊数据库
int result = userService.save(user);
// 提交事务 dataSourceTransactionManager.commit(transactionStatus);
// // 回滚事务
// dataSourceTransactionManager.rollback(transactionStatus);
return result;
}
}
Spring 声明式事务
声明式事务的实现很简单,只需要在需要的⽅法上添加@Transactional 注解就可以实现了,⽆需⼿动开启事务和提交事务,进⼊⽅法时⾃动开启事务,⽅法执⾏完会⾃动提交事务,如果中途发⽣了没有处理的异常会⾃动回滚事务
UserInfo 类
@Data
public class UserInfo {
private int id;
private String username;
private String password;
private String photo;
private LocalDateTime createtime;
private LocalDateTime updatetime;
private int state;
}
UserMapper接口
@Mapper
public interface UserMapper {
@Insert("insert into userinfo(username,password)values(#{username},#{password})")
int add(UserInfo userInfo);
}
UserService 服务层
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
public int add(UserInfo userInfo){
return userMapper.add(userInfo);
}
}
UserController控制层
@RestController
@RequestMapping("/user")
public class UserController {
@Resource
private UserService userService;
@RequestMapping("/add")
@Transactional//回滚
public int add(){
//1.非空判断
UserInfo userInfo=new UserInfo();
userInfo.setUsername("zhangshan");
userInfo.setPassword("123456");
//2.调用Service执行添加
int result=userService.add(userInfo);
System.out.println("result"+result);
//3.将结果给前端
return result;
}
}
@Transactional 作⽤范围
@Transactional 可以⽤来修饰⽅法或类:
-
修饰⽅法时:需要注意只能应⽤到 public ⽅法上,否则不⽣效。推荐此种⽤法。
-
修饰类时:表明该注解对该类中所有的 public ⽅法都⽣效。
@RequestMapping("/save")
@Transactional(isolation = Isolation.SERIALIZABLE)
public Object save(User user) {
// 业务实现
}
事务不回滚的问题:
诺是在事务中的异常被程序捕获了,并没有被Transactional 识别出异常。此时就认为正常情况,就不会滚了。
如何解决:
1.让Transactional 感知异常,将异常抛回程序。
2.通过手动书写代码,实现回滚操作
//手动回滚事务
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
事务的传播机制
事务隔离级别是保证多个并发事务执⾏的可控性的(稳定性的),⽽事务传播机制是保证⼀个事务在多个调⽤⽅法间的可控性的(串行)(稳定性的)
事务的传播机制规定了:多个事务在在相互调用时,事务的执行行为。
Spring 事务传播机制包含以下 7 种:
- Propagation.REQUIRED(需要):默认的事务传播级别,它表示如果当前存在事务,则加⼊该事务;如果当前没有事务,则创建⼀个新的事务。
- Propagation.SUPPORTS(支持):如果当前存在事务,则加⼊该事务;如果当前没有事务,则以⾮事务的⽅式继续运⾏。(起始点没有事务,之后的链条就不执行事务;起始点有事务,之后的链条就加入事务)
- Propagation.MANDATORY:(mandatory:强制性)如果当前存在事务,则加⼊该事务;如果当前没有事务,则抛出异常
- Propagation.REQUIRES_NEW:表示创建⼀个新的事务,如果当前存在事务,则把当前事务挂起。也就是说不管外部⽅法是否开启事务,Propagation.REQUIRES_NEW 修饰的内部⽅法会新开启⾃⼰的事务,且开启的事务相互独⽴,互不⼲扰。
- Propagation.NOT_SUPPORTED:以⾮事务⽅式运⾏,如果当前存在事务,则把当前事务挂起。
- Propagation.NEVER:以⾮事务⽅式运⾏,如果当前存在事务,则抛出异常。
- Propagation.NESTED:如果当前存在事务,则创建⼀个事务作为当前事务的嵌套事务来运⾏;如果当前没有事务,则该取值等价于 PROPAGATION_REQUIRED。
事务链的低端,发生异常,事务链的顶端因为调用低端方法。同时也感受到了异常,使整个事务链回滚。怎么在他的异常点中回滚。很简单,通过手动回滚操作。对保存点进行回滚,从而不会进行整个链条回滚。
REQUIRED是一个正式员工:NESTED是REQUIRED的零时工,而NESTED自己嵌套了一个NESTED(也就是自己给自己请了零时工)。此时系统将这两个NESTED放成一个NESTED。只要这两个NESTED但凡一个错误。两个零时工一起完蛋。
//手动回滚事务
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
@RestController
public class UserController {
@Resource
private UserService userService;
@Resource
private LogService logService;
@RequestMapping("/save")
@Transactional(propagation = Propagation.REQUIRED)
public Object save(User user) {
// 插⼊⽤户操作
userService.save(user);
// 插⼊⽇志
logService.saveLog("⽤户插⼊:" + user.getName());
return true;
}
}