hibernate事物的并发处理

1.事物的特性：ACID ==>Atomic (原子性)   Consistency(一致性)   Itegrity(独立性)   Durability(持久性)

2.脏读：读了另外一个事物没有提交的数据；不可重复读：对同一个数据，前后两次读的值是不一样的；幻读：说的是插入与更新的问题，在你读的过程中，另外一个事物往里头插了一条心的数据，影响了你读的结果

3.数据库事物隔离机制

　　Read Uncommitted

　　一个会话可以读取其他事务未提交的更新结果，如果这个事务最后以回滚结束，这时的读取结果就可能是错误的，所以多数的数据库应用都不会使用这种隔离级别。

　　Read Committed

　　这是SQL Server的缺省隔离级别，设置为这种隔离级别的事务只能读取其他事务已经提交的更新结果，否则，发生等待，但是其他会话可以修改这个事务中被读取的记录，而不必等待事务结束，显然，在这种隔离级别下，一个事务中的两个相同的读取操作，其结果可能不同。

　　Read Repeatable

　　在一个事务中，如果在两次相同条件的读取操作之间没有添加记录的操作，也没有其他更新操作导致在这个查询条件下记录数增多，则两次读取结果相同。换句话说，就是在一个事务中第一次读取的记录保证不会在这个事务期间发生改变。SQL Server是通过在整个事务期间给读取的记录加锁实现这种隔离级别的，这样，在这个事务结束前，其他会话不能修改事务中读取的记录，而只能等待事务结束，但是SQL Server不会阻碍其他会话向表中添加记录，也不阻碍其他会话修改其他记录。（其他会话：不能修改当前会话读的数据，但是可以添加数据---》可以幻想读）

　　Serializable

　　在一个事务中，读取操作的结果是在这个事务开始之前其他事务就已经提交的记录，SQL Server通过在整个事务期间给表加锁实现这种隔离级别。在这种隔离级别下，对这个表的所有DML操作都是不允许的，即要等待事务结束，这样就保证了在一个事务中的两次读取操作的结果肯定是相同的。

4.设定hibernate事物隔离级别

hibernate.connection.isolation=2==>可取值（1，2,4,8）

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

session.load(CLass,id,LockMode.UPGRADE)

hibernate锁有：LockMode.None无锁的机智，Transaction结束时，切换到此模式

                             LockMode.Read在查询的时候，hibernate会自动获取锁

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

以上三种锁的模式，是hibernate内部使用的

LockMode.UPGRADE_NOWAIT   ORACLE支持的锁的方式

                             

乐观锁：需要加上一个version（版本）

@Version