HIbernate——事务并发问题及处理（乐观锁悲观锁）

一、事物并发三种常见问题

1.dirty read 脏读

时间 事物A 事物B T1 开始事物 开始事物 T2 查询账户余额为1000 T3 汇入100把余额变为1100 T4 读取账户余额为1100 T5 回滚 T6 取款1100 T7 提交事物失败

事物A读到了事物B还没有提交的数据

2.non-repeatable read 不可重复读

时间 事物A 事物B T1 开始事物 T2 开始事物 T3 查询账户余额为1000 T4 汇入100把余额变为1100 T5 提交事物 T6 T7 查询余额为1100 T8 提交事物

事物A第一次读余额为1000，B在中间提交了一次事物把余额改为了1100，事物A再读取余额变为了1100。读取同一个数据得到了了两个不同的结果

3.phantom read 幻读

时间 事物A 事物B T1 开始事物 T2 开始事物 T3 查询学生数为10人 T4 插入一个学生 T5 查询学生数为11人 T6 提交事物 T7 提交事物

事务A执行两次查询，第二次结果集包含第一次中没有或者某些行已被删除，造成两次结果不一致，是事务B在这两次查询中间插入或者删除了数据造成的。

不可重复读和幻读的区别在与一个是前者强调更新，后者强调插入和删除。

二、事物隔离机制

1.read uncommitted 可读未提交
2.read committed 可读已提交
3.repeatable read 可重复读
4.serializable 串行化

隔离级别 是否脏读 是否不可重复读 是否幻读 read uncommitted 是 是 是 read committed 否 是 是 repeatable read 否 否 是 serializable 否 否 否

隔离级别越高，效率越低。

一般把事物级别设为2：read committed
如果不设置事物级别，则根据数据库的默认级别来设置，如MySQL默认级别是repeatable read

设定Hibernate的事物隔离机级别

1：read uncommitted；2：read committed；4：repeatable read；8：serializable

<property name="hibernate.connection.isolation">2</property>

三、乐观锁和悲观锁

当事务隔离级别设为2（read committed）时，任会出现non-repeatable read和phantom read（很少出现，可以忽略）问题。因此我们需要乐观锁或悲观锁来解决non-repeatable read 问题。

悲观锁

悲观锁假定当前事务操纵数据资源时，可能会有其他事务同时访问该数据资源，为了避免当前事务的操作受到干扰，先锁定资源。尽管悲观锁能够防止丢失更新和不可重复读这类并发问题，但是它影响并发性能，因此应该很谨慎地使用悲观锁。

select … for update

Hibernate3

User u =(User)session.get(User.class,1,LockMode.UPGRADE);

在Hibernate3.6以上的版本中”LockMode”已经不建议使用
Hibernate4

User u =(User)session.get(User.class,1,LockOptions.UPGRADE);

在读取数据时，借助数据库为这条数据上锁，即在sql语句后加上 for update,在这个事物提交前，其他事物无法对这条数据进行改动。

乐观锁

乐观锁假定当前事务操纵数据资源时，不会有其他事务同时访问该数据资源，因此不作数据库层次上的锁定。为了维护正确的数据，乐观锁使用应用程序上的版本控制（由程序逻辑来实现的）来避免可能出现的并发问题。

private int version;@Version    public int getVersion() {        return version;    }    public void setVersion(int version) {        this.version = version;    }

在表里加上一个version字段，记录当前的版本号，更新数据时version会加1。将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则更新，否则就报错。
比如
事物A取出一条记录，当前版本号为0，更改记录后版本号增加1。如果在事物A提交前有个事物B更新了该数据，数据库内的版本号变为了1，A再提交时就会报错。