事务隔离机制 && Hibernate悲观锁、乐观锁

背景：

       不管是在哪里，事务的并发性都是一个问题，所以专门存在一种事务隔离机制去解决这种事务并发所造成的问题。

一、什么是事务隔离级别：

       事务隔离级别是一个失误对数据库的修改与并行的另一个事务的隔离程度。

二、事务并发会造成哪些问题：

       1、脏读：一个事务读到另一事务未提交的更新数据。

   

       2、不可重复读（虚读）：在同一事务中，多次读取同一数据返回的结果有所不同。

   

       3、不可重复读（幻读）：一个事务读取到另一个事务未提交的insert数据

   

       4.1丢失更新一 ：A事务撤销时，覆盖（已经提交的B事务的更新数据）

   

       4.2丢失更新二：A事务提交时，覆盖（B事务已经提交的数据）

   

三、解决方案——事务隔离级别：

       1、Read_UNCOMMITTED：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

       

       2、READ_COMMITTED：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

       

       3、RRPEATABLE_READ：禁止不可重复读取和脏读取，但是有时可能出现幻读数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

       

       4、SERIALIZABLE：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

小结：

       隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

四、Hibernate中的解决方案：

     首先设置hibernate.connection.isolation的值为2——READ_COMMITTED，这样他就会使用JDBC中的COMMITTED隔离机制。但是这样一就解决不了不可重复度的问题。所以拓展一下Hibernate著名的悲观、乐观锁

1、悲观锁：

       悲观锁不是一种锁，准确的来说是一种悲观的加锁方案。因为它总是认为别的事务会修改他读取的数据，所以在读取数据时就立刻加上排它锁，防止别人修改其读取的数据，这种行为就是悲观锁。悲观锁避免更新丢失的原理和SERIALIZABLE隔离级别一样，保证第二个事务读取的是第一个事务已经提交后的数据。不过与SERIALIZABLE隔离级别不同的是：SERIALIZABLE隔离级别是让数据库的所机制负责为select加共享锁，影响面非常广，而悲观锁是通过手工为select加排它锁，有你自己决定对哪些select语句加锁。

手工为select语句加排它锁的语法：

Select * from Table where id=condition for update

应用中的实现为：

String hqlStr  =  " from TUser as user where user.name=’Erica’ "; 
Query query =  session.createQuery(hqlStr); 
query.setLockMode(" user " ,LockMode.UPGRADE);  // 加锁  
List userList  =  query.list(); // 执行查询，

这里还有一个特殊的东西，针对Oracle来说，他有一个特定实现就是nowait，不等待：

select * from Table where id=condition for update nowait

举例：

sql_1:select * from Table where id=condition for update;
sql_2:select * from Table where id=condition for update;
sql_3:select * from Table where id=condition for update nowait;

这样执行：执行sql_1不提交，Table表被锁住；执行sql_2，被阻塞，等待sql_1提交；执行sql_3,因为有nowait，立即返回错误："ORA-00054 : 资源正忙,但指定以NOWAIT方式获取资源"

2、乐观锁：

       乐观锁同样也不是一种锁，是一种乐观的加锁方案。它认为别人不会修改它读取的数据，所以在读取数据时并不为记录加排它锁。但是他也有自己的方法来防止并发事务覆盖啊前面事务所做的更新，原理就是在数据库中加一个版本字段，每次执行update语句的时候这个字段安都会进行累加，当其他事务以旧版本的值来更新记录时，由于前面事务的update语句已经累加了版本字段，所以其他食物会找不到相应记录，通过这种方式来避免更新丢失。

这个实现起来比较简单：在POJO上面加上一个Version字段 ，就可以了。
   

 @Version
    private int version ;

五、总结Hibernate的加锁模式：

 LockMode.NONE ：无锁机制。
 LockMode.WRITE ：Hibernate在 Insert和 Update记录的时候会自动获取。
 LockMode.READ ：Hibernate在读取记录的时候会自动获取。
       以上这三种锁机制一般由 Hibernate内部使用，如Hibernate为了保证 Update过程中对象不会被外界修改，会在 save 方法实现中自动为目标对象加上 WRITE锁。

 LockMode.UPGRADE ：利用数据库的 for update 子句加锁。
 LockMode. UPGRADE_NOWAIT ： Oracle的特定实现，利用 Oracle的 for update nowait子句实现加锁。
 面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
 Criteria.setLockMode
 Query.setLockMode