数据库的事务

 

一、数据库事务

就是多个SQL语句（一个团队），要么所有执行success，不然就fail。 它最终的目标：数据不会被破坏。即事务操作成功，数据的结果和业务期待的结果是一致的。这也就是ACID中的一致性（Consistency）。那什么是ACID。

 

二、ACID

即原子性、一致性、隔离性和持久性。下面一一生动解释： a）原子性 原子是物质的最小单元，即不可再分。 每一个简单的 SQL 语句即包含在一个事务中，具有原子性。b）一致性 终极目标：数据不会被破坏。（这不是废话？确实有点）具体说，事务操作成功后，数据库所处的状态和它的业务规则是一致的，即数据不会被破坏。举个栗子：两句UPDATE语句，从A账户转账到B账户，不管成功失败，A和B账户的总额是不变的。c）隔离性 隔离：表示互不干扰。事务与事务之间无法干扰，即每个事务独立，不会交叉。这样可以让多个线程并发访问数据库。

 d）持久性数据必须持久化到数据库（存储在磁盘）中。已提交的事务，即使在提交后数据库崩溃，重启数据库时也能够根据日志对未持久化的数据进行重执行操作。

三 脏度，不可重复读 与幻读 

 大部分数据库事务操作都是并发执行的，这就可能遇到下面的几种问题：

丢失更新

：两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，后果比较严重。一般是由于没加锁的原因造成的。

脏读 ：指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问 这个数据，然后使用了这个数据。

 

不可重复读

不可重复读的重点是修改:

同样的条件, 你读取过的数据, 再次读取出来发现值不一样了

例子：

在事务1中，Mary 读取了自己的工资为1000,操作并没有完成 

con1 = getConnection();
select salary from employee empId ="Mary";

在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务. 

con2 = getConnection();
update employee set salary = 2000;
con2.commit();

在事务1中，Mary 再次读取自己的工资时，工资变为了2000 

//con1
select salary from employee empId ="Mary";

在一个事务中前后两次读取的结果并不致，导致了不可重复读。

 幻读

幻读的重点在于新增或者删除

同样的条件, 第1次和第2次读出来的记录数不一样

例子：

目前工资为1000的员工有10人。 
事务1,读取所有工资为1000的员工。 

con1 = getConnection();
Select * from employee where salary =1000;

共读取10条记录 

 

这时另一个事务向employee表插入了一条员工记录，工资也为1000 

con2 = getConnection();
Insert into employee(empId,salary) values("Lili",1000);
con2.commit();

事务1再次读取所有工资为1000的员工 

//con1
select * from employee where salary =1000;

共读取到了11条记录，这就产生了幻像读。 

 为了处理这几种问题，SQL定义了下面的4个等级的事务隔离级别：

 

未提交读（READ UNCOMMITTED ）：最低隔离级别，一个事务能读取到别的事务未提交的更新数据，很不安全，可能出现丢失更新、脏读、不可重复读、幻读；

提交读（READ COMMITTED）：一个事务能读取到别的事务提交的更新数据，不能看到未提交的更新数据，不会出现丢失更新、脏读，但可能出现不可重复读、幻读；

可重复读（REPEATABLE READ）：保证同一事务中先后执行的多次查询将返回同一结果，不受其他事务影响，不可能出现丢失更新、脏读、不可重复读，但可能出现幻读；

序列化（SERIALIZABLE）：最高隔离级别，不允许事务并发执行，而必须串行化执行，最安全，不可能出现更新、脏读、不可重复读、幻读，但是效率最低。

隔离级别越高，数据库事务并发执行性能越差，能处理的操作越少。

所以一般地，推荐使用REPEATABLE READ级别保证数据的读一致性。对于幻读的问题，可以通过加锁来防止。

MySQL支持这四种事务等级，默认事务隔离级别是REPEATABLE READ。

Oracle数据库支持READ COMMITTED 和 SERIALIZABLE这两种事务隔离级别，所以Oracle数据库不支持脏读。Oracle数据库默认的事务隔离级别是READ COMMITTED。

 

spring @Transactional注解参数详解

事物注解方式: @Transactional

当标于类前时, 标示类中所有方法都进行事物处理 ,

 

当类中某些方法不需要事物时:

 @Transactional(propagation =Propagation.NOT_SUPPORTED)

 public List getAll() { 
 return null; 
 } 

 

事物传播行为介绍:

 

　　@Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)

　　@Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务

　　@Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务

　　@Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行,否则抛出异常

　　@Transactional(propagation=Propagation.NEVER) ：必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反)

　　@Transactional(propagation=Propagation.SUPPORTS) ：如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务.

 

事务隔离级别:

Isolation，该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置

 

　　@Transactional(isolation = Isolation.READ_UNCOMMITTED)：读取未提交数据(会出现脏读, 不可重复读) 基本不使用

　　@Transactional(isolation = Isolation.READ_COMMITTED)：读取已提交数据(会出现不可重复读和幻读)

　　@Transactional(isolation = Isolation.REPEATABLE_READ)：可重复读(会出现幻读)

　　@Transactional(isolation = Isolation.SERIALIZABLE)：串行化

 

rollbackFor

该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。例如：

指定单一异常类：@Transactional(rollbackFor=RuntimeException.class)

指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})

 

noRollbackFor

该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。例如：

指定单一异常类：@Transactional(noRollbackFor=RuntimeException.class)

指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class, Exception.class})

 

@Transactional 注解应该只被应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错， 但是这个被注解的方法将不会展示已配置的事务设置。

@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而，请注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅 是一种元数据，能够被可以识别 @Transactional 注解和上述的配置适当的具有事务行为的beans所使用。上面的例子中，其实正是 元素的出现 开启 了事务行为。

Spring团队的建议是你在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解，但是这将只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装（将被确认为严重的）。因此，请接受Spring团队的建议并且在具体的类上使用 @Transactional 注解。

评论

1 楼 dbp_cn 2017-03-24  

http://www.cnblogs.com/fjdingsd/p/5632949.html