spring事务整理一

工作很多年了，整理下自己的知识体系。

spring为了方便事务管理，提供了注解与xml配置事务的形式。

业务中事务使用时注意点：

1.避免超长事务，影响性能及吞吐量，特别是一般业务在开启事务时会加数据库行级锁，如果事务超长会影响其它事务的操作。

2.将回滚设置为：throwable，即对于任何throwable及其子类异常都能够回滚。

3.加锁一定要加有索引的记录上，否则会导致表锁

4.避免在事务中做耗时的io或其它操作

Spring实现事务是做了一个try catch，如果应用程序发生异常，并且是要回滚的异常则回滚。

无论是注解还是配置，最终都是aop代理去做事务管理。

目的：

方便事务管理

事务本身的问题：

a.脏读

事务读取了另一个事务未提交的事务。

解决办法：读已提交的事务

c.不可重复读

指一个事务在两个时间点读取数据时，由于第二次读取前数据被另外一个事务修改因此出现两次数据读取不一致。

解决办法：事务在读取时，加数据库行级锁。

b.幻读

指事务在第一次读取行数时有100条，第二次读取前，另一个事务插入了一条，就变成了我101条。

解决办法： 在这个事务做业务操作时，不允许插入事务，这种性能太差了。

事务几个要点：

1.隔离级别

即事务可见性，spring提供：

a.read_uncommited：会出现脏读，不可重复读，幻像读，

b.read_commited：解决了脏读，会出现不可重复读，幻像读。

c.可重复读隔离级别：解决脏读，可重复读问题，会出现幻像读。

d.串形化，事务串形化执行：解决脏读，不可重复读，幻像读。

2.传播级别

a.required,

总是需要有一个事务，没有起一个。

b.required_new,

总是另起一个事务执行。

c.support，

支持事务，没事务则以非事务执行。

d.not_support,

不支持，即使当前有事务也以非事务执行。

e.never

不支持事务，如果当前存在事务抛错。

f.mandatory强制

必须要求有事务，没有则抛错。

g.nested

统一提交但是不统一回滚，可以理解成父子事务，提交一起提交，如果子事务失败不影响父事务提交。父事务失败影响子事务提交。

3.事务超时时间

一般设置成30秒

4.什么异常要回滚

默认runtimexception，开发时注意设置为throwable