事务相关知识(传播特性,隔离级别,锁)

上接 : 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_REPEATABLE_READ </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-------------------------------------------------------------

 

你可能感兴趣的:(隔离级别)