上接 : EJB事务控制（CMT和BMT两种方式以及JTA事务）

上篇代码: @TransactionAttribute(TransactionAttributeType.REQUIRED)  //设置事务的传播特性为required

上篇文章为什么设置传播特性为: required?

       事务的传播特性有7个:

       1. PROPAGATION_REQUIRED: 如果存在一个事务，则支持当前事务。如果没有事务则开启
       2. PROPAGATION_SUPPORTS: 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行
       3. PROPAGATION_MANDATORY: 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。
       4. PROPAGATION_REQUIRES_NEW: 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。
       5. PROPAGATION_NOT_SUPPORTED: 总是非事务地执行，并挂起任何存在的事务。
       6. PROPAGATION_NEVER: 总是非事务地执行，如果存在一个活动事务，则抛出异常
       7. PROPAGATION_NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务,

       吉屋项目一直用的传播特性是: REQUIRES_NEW, 所以在测试ejb事务的时候一直不成功, 因为DAO设置的传播特性也是REQUIRES_NEW, 它会新开启一个事务, 这个事务会提交

上篇文章事务是成功的, 如果并发事务怎么办?

       SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
       1. Read Uncommitted（读取未提交内容）
       在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
　　  2.Read Committed（读取提交内容）
       这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
       3.Repeatable Read（可重读）
       这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
       4.Serializable（可串行化）
       这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

       如何查看隔离级别

       在mysql中可以使用: select @@GLOBAL.tx_isolation, @@tx_isolation  查询事务隔离级别

                  @@GLOBAL.tx_isolation: 系统当前隔离级别

                  @@tx_isolation: 会话当前隔离级别

       如何修改隔离级别

                 设置当前会话隔离级别  set session transaction isolation level repeatable read;

                 设置系统当前隔离级别  set global transaction isolation level repeatable read;

       在EJB事务中如何设置隔离级别

                 <transaction-isolation>TRANSACTION_SERIALIZABLE</transaction-isolation>

设置了最高的隔离级别是否就大功告成?

       现在有2个事务:

          对某用户的余额进行添加, 当前余额为:10000

          A: 查询一个用户; 余额添加2000;

          B: 查询这个用户; 余额添加3000;

       假定A先执行查询操作, A事务commit之前执行B事务也执行了查询操作; 然后A事务commit;

       问: 最后余额是多少? 为什么余额不是15000?

        这里就涉及到了数据库的锁机制, MYSQL锁机制有以下几种

        共享锁
             共享锁的代号是S，是Share的缩写，共享锁的锁粒度是行或者元组（多个行）。一个事务获取了共享锁之后，可以对锁定范围内的数据执行读操作。

        排它锁
            排它锁的代号是X，是eXclusive的缩写，排它锁的粒度与共享锁相同，也是行或者元组。一个事务获取了排它锁之后，可以对锁定范围内的数据执行写操作。
            假设有两个事务t1和t2
            如果事务t1获取了一个元组的共享锁，事务t2还可以立即获取这个元组的共享锁，但不能立即获取这个元组的排它锁（必须等到t1释放共享锁之后）。
            如果事务t1获取了一个元组的排它锁，事务t2不能立即获取这个元组的排共享锁，也不能立即获取这个元组的排它锁（必须等到t1释放排它锁之后）。
 
        意向锁
           意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁(IS)和意向排它锁(IX)两类。意向共享锁表示一个事务有意对数据上共享锁或者排它锁。“有意”这两个字表达的意思比较微妙，说的明白点就是指事务想干这个事但还没真去干。举例说明下意向共享锁，比如一个事务t执行了这样一个语句：select * from table lock in share model ，如果这个语句执行成功，就对表table上了一个意向共享锁。lock in share model就是说事务t1在接下来要执行的语句中要获取S锁。如果t1的select * from table lock in share model执行成功，那么接下来t1应该可以畅通无阻的去执行只需要共享锁的语句了。意向排它锁的含义同理可知，上例中要获取意向排它锁，可以使用select * from table for update 。

        所以上面的问题我们应该这么解决:

           A事务:
           select @@GLOBAL.tx_isolation, @@tx_isolation
           set session transaction isolation  level serializable;
           start transaction;
           select * from users where uid=1 for update;
           update 余额+2000 (在hibernate里面要先查出来才能update, 所以这里不好展示)
           commit;

           B事务:
           select @@GLOBAL.tx_isolation, @@tx_isolation
           set session transaction isolation  level serializable;
           start transaction;
           select * from users where uid=1 for update;
           update 余额+3000 (在hibernate里面要先查出来才能update, 所以这里不好展示)
           commit;

       以上代码也可以用来测试事务隔离级别等.

--------------------------------------by fancie-------------------------------------------------------------