hbn多事务

事务果然不是个好解决的东西 尤其是 sp+hbn整合后出现了aop就开始晕了 最近要慢慢整理下 理清思路 先看下 普通的hbn多事务更新的内容

Transaction如果不隔绝，则在多个transactions访问数据库时容易产生如下问题：

1，Lost update - 两个transactions同时更新同一行，由于第2个transaction的abort，造成2个更新都失去。这一般发生在系统没有对transaction进行隔绝。

2，Dirty read - 一个transaction正在读取另一个还没有commited的transaction对数据库做的改变。如果第2个transaction roll back,那么第一个transaction读取的信息就是不同步的。

3，Unrepeatable read - 一个transaction对数据库中同一行数据读取了2遍，但是读取出来的数据却不同。这可能发生的情况是在这两次读取的间隔另一个transaction对该行做了更新。

4，Second lost updates problem - 这种问题是Unrepeatable read的一种特例。当2个transactions同时读取一行，其中一个对该行做了更新并且commited,此时另外一transaction可能也会对此行做更新。那么第一个transaction做的改变就失效了。

5，Phantom read - 一个transaction执行了2次同一个query，但是第2次query读出的结果集合有第一个不存在的行。这发生在在两次query执行之间另一个transaction新增了新行。

为了解决以上问题，引入了Transaction Isolation的概念，并且对Isolation做了分级。

ANSI SQL和JTA定义的Isolation Level是一致的，包括以下四种Level：

1，Read uncommitted - 允许Dirty Read但是不允许Lost update。即一个transaction在更新数据库的一行时，别的Transaction不能对其做写操作，只能做读操作。这是通过排它写锁实现的。

2，Read committed - 允许Unrepeatable reads但是不允许Dirty reads。对一行做读操作的transactions不会block其它访问改行的transaction，但是一个没有committed的对该行进行写操作的transaction会block掉其它的transaction（包括读操作的transaction）。这是通过排它写锁和瞬时的共享读锁实现的。

3，Repeatable Read - 在此level下，只有Phantom read可能发生。当一个transaction对数据库进行读操作时候，它会block掉其它全部的transactions（不包括只读的transactions），而一个对数据库进行写操作的transaction就会block掉其它全部的transactions。这是通过排它写锁和共享读锁实现的。

4，Serializable - 这是最严格的Isolation level。他让全部的transactions以线性的方式依次执行。这是通过排它锁实现的。

Hibernate中设置隔绝类型的方法：

在cfg里面修改hibernate.connection.isolation属性。相关可选属性：
1—Read uncommitted isolation
2—Read committed isolation
4—Repeatable read isolation
8—Serializable isolation