并发事务

在开发环境中，对于同时运行的多个事务，在访问数据库中相同的数据时，没有采用必要的隔离机制，就会导致各种并发问题。如下：

1.丢失更新：

第一类：撤销事务时，把其他事务已经提交更新的数据覆盖。

举例：事务1和事务2对同一条数据进行更新操作，事务1更新操作失败，回滚时，事务2的操作也失效了，数据又回到事务1修改前的状态。

第二类：一个事务覆盖另一个事务已经提交的数据。（是不可重复的特殊情况）

举例：两个事务都读取同一行，然后两个事务都进行写操作并提交，第一个事务所做的操作就会丢失。

2.脏读：一个事务读取到另一个事务未提交的更新数据。

3.虚读：一个事务读到另一个事务已经提交的新插入的数据。（符合搜索条件的一行数据在后面的读取操作中出现，但该行数据却不属于最初的数据）

举例来说：事务1 读取满足某种搜索条件的一些行，然后  事务2插入了符合 事务1的搜索条件的一个新行。如果事务1 重新执行产生原来那些行的查询，就会得到不同的行。

4.不可重复读：一个事务读到另一个事务已经更新的数据。

举例来说：事务1 读取一行数据，然后 事务 2  修改或删除该行并提交修改操作。当事务1试图重新读取该行时，它就会得到不同的数据值（如果该行被更新）或发现该行不再存在（如果该行被删除）。

为了解决数据库事务并发时产生的问题，数据库系统提供4种事务隔离级别：     

由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

√: 可能出现    ×: 不会出现

	脏读	不可重复读	虚读
Read uncommitted(可读未提交）	√	√	√
Read committed（可读已提交）	×	√	√
Repeatable read（可重复读）	×	×	√
Serializable（串行化）	×	×	×

 在Hibernate的配置文件中可以显式地配置数据库事务隔离级别，使用hibernate.connection.isolation。每一个隔离级别用一个整数表示：

8-Serializable

4-Repeatable read

2-Read committed

1-Read uncommitted

Hibernate支持两种锁机制： 
即通常所说的“悲观锁（Pessimistic Locking）”和 “乐观锁（OptimisticLocking）”。 


悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 


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子句实现加锁。 

 Hibernate的悲观锁，也是基于数据库的锁机制实现。 下面的代码实现了对查询记录的加锁：

String hql = "from USER as u where u.name='lily'";
Query query = session.createQuery(hql);
query.setLockMode("u",LockMode.UPGRADE);//加锁
List users = query.list()//执行查询

获取数据 query.setLockMode 对查询语句中特定别名所对应的记录进行加锁（我们为 User类指定了一个别名“u”），这里也就是对返回的所有user记录进行加锁。 观察运行期Hibernate生成的SQL语句： 
1  select user0_.id as id, user0_.name as name, user0_.group_id as group_id, user0_.user_type as user_type, user0_.sex as sex from u user0_ where (user0_.name = ’lily’ )  for  update
 这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。 


上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现： 
Criteria.setLockMode 
Query.setLockMode 
Session.lock 
注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会 真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update 子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

乐观锁，大多是基于数据版本（Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 


1． 首先为TUser的class描述符添加optimistic-lock属性：

<hibernate-mapping>
<class name="org.hibernate.sample.User" table="user" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
......
</class>
</hibernate-mapping>

 添加一个Version属性描述符 
代码内容

<hibernate-mapping>
<class name="org.hibernate.sample.User" table="user" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
<id name="id" column="id" type="java.lang.Integer">
<generator class="native"></generator>
</id>
<version column="version" name="version" type="java.lang.Integer"/>
......
</class>
</hibernate-mapping>

注意version 节点必须出现在ID 节点之后。
这里我们声明了一个version属性，用于存放用户的版本信息，保存在User表的 version字段中。 此时如果我们尝试编写一段代码，更新User表中记录数据，如：
代码内容

Criteria criteria = session.createCriteria(User.class);
criteria.add(Expression.eq("name","lily"));
List users = criteria.list();
User user = (User)users.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1);//更新UserType字段
tx.commit();

每次对User进行更新的时候，我们可以发现，数据库中的version都在递增。 而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为lily 的用 户进行操作，以模拟并发更新时的情形： 
代码内容

Session session = getSession();
Criteria criteria = session.createCriteria(User.class);
criteria.add(Expression.eq("name","lily"));
Session session2 = getSession();
Criteria criteria = session2.createCriteria(User.class);
criteria.add(Expression.eq("name","lily"));
List users = criteria.list();
List users2 = criteria.list();
User user=users.get(0);
User user2=users.get(0);
Transaction tx1=session.beginTransaction();
Transaction tx1=session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();

执行以上代码，代码将在tx.commit()处抛出StaleObjectStateException异 常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我 们就可以在乐观锁校验失败时进行相应处理。 

悲观锁与乐观锁的比较: 
1.悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受; 
2.相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。
3.系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。 
Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。 
Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。 
optimistic-lock属性有如下可选取值： 
Ø none 无乐观锁 
Ø version 通过版本机制实现乐观锁 
Ø dirty 通过检查发生变动过的属性实现乐观锁 
Ø all 通过检查所有属性实现乐观锁 
其中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。