数据库事务并发可能出现的问题——事务的隔离机制和乐观、悲观锁

一、事务ACID

1. Atomicity（原子性）

2. Consistency（一致性）

3. Isolation（隔离性）

4. Durability（持久性）

二、事务并发可能出现的问题

第一类丢失更新(Lost Update) 撤销一个事务时，把其他事务已提交的更新数据覆盖



2. dirty read脏读 (读到了另一个事务在处理中还未提交的更新数据)



3. non-repeatable read 不可重复读 (一个事务读取到另一个事务已提交的更新数据，前后读取的数据不一致，事务无法确定使用哪个数据！)



4. second lost update problem 第二类丢失更新(不可重复读的特殊情况)



5. phantom read 幻读 （一个事务读取到另一个事务已提交的新插入的数据！）



三、事务的隔离机制

i. 查看 java.sql.Connection 文档

ii. 1：read-uncommitted 2：read-committed 4：repeatable read 8：serializable（数字代表对应值）

为什么取值要使用 1 2 4 8 而不是 1 2 3 4

1=0000 2=0010 4=0100 8=1000(位移计算效率高)

1. 只要数据库支持事务,就不可能出现第一类丢失更新

2. read-uncommitted(允许读取未提交的数据) 会出现dirty read, phantom-read,

non-repeatable read 问题

3. read-commited(读取已提交的数据 项目中一般都使用这个)不会出现dirty read,因为只有另

一个事务提交才会读出来结果，但仍然会出现 non-repeatable read 和 phantom-read

使用read-commited机制可用悲观锁 乐观锁来解决non-repeatable read 和 phantom-read问题

4. repeatable read(事务执行中其他事务无法执行修改或插入操作 较安全)

5. serializable解决一切问题(顺序执行事务 不并发，实际中很少用)



设定hibernate的事务隔离级别(使用hibernate.connection.isolation配置 取值1、2、4、8)

i. hibernate.connection.isolation = 2（如果不设 默认依赖数据库本身的级别）

ii. 用悲观锁解决repeatable read的问题（依赖于数据库的锁）

select … for update

使用另一种load方法–load(xx.class , i , LockMode.Upgrade)

a) LockMode.None无锁的机制，Transaction结束时，切换到此模式

b) LockMode.read在査询的时候hibernate会自动获取锁

c) LockMode.write insert update hibernate 会自动获取锁

d) 以上3种锁的模式，是hibernate内部使用的(不需要设)

e) LockMode.UPGRADE_NOWAIT是 ORACLE 支持的锁的方式

四、 乐观锁

Hibernate(JPA)乐观锁定(ReadCommitted)

实体类中增加version属性(数据库也会对应生成该字段,初始值为0)，并在其get方法前加

@Version注解，则在操作过程中没更新一次该行数据则version值加1，即可在事务提交前判断该数据是否被其他事务修改过.