当前位置 博文首页 > 文章内容

    数据库的特性和事务的特性

    作者: 栏目:未分类 时间:2020-07-08 18:01:35

    本站于2023年9月4日。收到“大连君*****咨询有限公司”通知
    说我们IIS7站长博客,有一篇博文用了他们的图片。
    要求我们给他们一张图片6000元。要不然法院告我们

    为避免不必要的麻烦,IIS7站长博客,全站内容图片下架、并积极应诉
    博文内容全部不再显示,请需要相关资讯的站长朋友到必应搜索。谢谢!

    另祝:版权碰瓷诈骗团伙,早日弃暗投明。

    相关新闻:借版权之名、行诈骗之实,周某因犯诈骗罪被判处有期徒刑十一年六个月

    叹!百花齐放的时代,渐行渐远!



    一、四大特性

    ⑴ 原子性(Atomicity)

    原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚,这和前面两篇博客介绍事务的功能是一样的概念,因此事务的操作如果成功就必须要完全应用到数据库,如果操作失败则不能对数据库有任何影响。

    ⑵ 一致性(Consistency)

    一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态。

      拿转账来说,假设用户A和用户B两者的钱加起来一共是5000,那么不管A和B之间如何转账,转几次账,事务结束后两个用户的钱相加起来应该还得是5000,这就是事务的一致性。

    ⑶ 隔离性(Isolation)

    隔离性是当多个用户并发访问数据库时,比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。

      

    ⑷ 持久性(Durability)

    持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

      例如我们在使用JDBC操作数据库时,在提交事务方法后,提示用户事务操作完成,当我们程序执行完成直到看到提示后,就可以认定事务以及正确提交,即使这时候数据库出现了问题,也必须要将我们的事务完全执行完成,否则就会造成我们看到提示事务处理完毕,但是数据库因为故障而没有执行事务的重大错误。

    二、事务的隔离性

    1,脏读

    脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。

      当一个事务正在多次修改某个数据,而在这个事务中这多次的修改都还未提交,这时一个并发的事务来访问该数据,就会造成两个事务得到的数据不一致。例如:用户A向用户B转账100元,对应SQL命令如下

    2,不可重复读

    不可重复读是指在对于数据库中的某个数据,一个事务范围内多次查询却返回了不同的数据值,这是由于在查询间隔,被另一个事务修改并提交了。

      例如事务T1在读取某一数据,而事务T2立马修改了这个数据并且提交事务给数据库,事务T1再次读取该数据就得到了不同的结果,发送了不可重复读。

      不可重复读和脏读的区别是,脏读是某一事务读取了另一个事务未提交的脏数据,而不可重复读则是读取了前一事务提交的数据。

      在某些情况下,不可重复读并不是问题,比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题,例如对于同一个数据A和B依次查询就可能不同,A和B就可能打起来了……

    3,虚读(幻读)

    幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作,这时事务T2又对这个表中插入了一行数据项,而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据,会发现还有一行没有修改,其实这行是从事务T2中添加的,就好像产生幻觉一样,这就是发生了幻读。

      幻读和不可重复读都是读取了另一条已经提交的事务(这点就脏读不同),所不同的是不可重复读查询的都是同一个数据项,而幻读针对的是一批数据整体(比如数据的个数)。

     

      现在来看看MySQL数据库为我们提供的四种隔离级别:

      ① Serializable (串行化):可避免脏读、不可重复读、幻读的发生。

      ② Repeatable read (可重复读):可避免脏读、不可重复读的发生。

      ③ Read committed (读已提交):可避免脏读的发生。

      ④ Read uncommitted (读未提交):最低级别,任何情况都无法保证。

    在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。

    在MySQL数据库中查看当前事务的隔离级别:

        select @@tx_isolation;

      在MySQL数据库中设置事务的隔离 级别

     set  [glogal | session]  transaction isolation level 隔离级别名称;
    
        set tx_isolation=’隔离级别名称;

    二、Spring七种事务的传播属性,五个隔离级别:

        
    七个事务传播属性
             propagation_required -- 支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择。
             propagation_supports -- 支持当前事务,如果当前没有事务,就以非事务方式执行。
             propagation_mandatory -- 支持当前事务,如果当前没有事务,就抛出异常。
             propagation_requires_new -- 新建事务,如果当前存在事务,把当前事务挂起。
             propagation_not_supported -- 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
             propagation_never -- 以非事务方式执行,如果当前存在事务,则抛出异常。
             propagation_nested--如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则进行与propagation_required类似的操作。
     
                1: PROPAGATION_REQUIRED
                加入当前正要执行的事务不在另外一个事务里,那么就起一个新的事务
                比如说,ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候,
                ServiceA.methodA已经起了事务,这时调用ServiceB.methodB,ServiceB.methodB看到自己已经运行在ServiceA.methodA
                的事务内部,就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中,他就会为自己分配一个事务。
                这样,在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常,事务都会被回滚。即使ServiceB.methodB的事务已经被
                提交,但是ServiceA.methodA在接下来fail要回滚,ServiceB.methodB也要回滚
     
                2: PROPAGATION_SUPPORTS
                如果当前在事务中,即以事务的形式运行,如果当前不再一个事务中,那么就以非事务的形式运行
     
                3: PROPAGATION_MANDATORY
                必须在一个事务中运行。也就是说,他只能被一个父事务调用。否则,他就要抛出异常
     
                4: PROPAGATION_REQUIRES_NEW
                这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED,ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW,
                那么当执行到ServiceB.methodB的时候,ServiceA.methodA所在的事务就会挂起,ServiceB.methodB会起一个新的事务,等待ServiceB.methodB的事务完成以后,
                他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务,那么就是存在
                两个不同的事务。如果ServiceB.methodB已经提交,那么ServiceA.methodA失败回滚,ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚,
                如果他抛出的异常被ServiceA.methodA捕获,ServiceA.methodA事务仍然可能提交。
     
                5: PROPAGATION_NOT_SUPPORTED
                当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ,而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ,
                那么当执行到ServiceB.methodB时,ServiceA.methodA的事务挂起,而他以非事务的状态运行完,再继续ServiceA.methodA的事务。
     
                6: PROPAGATION_NEVER
                不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED, 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ,
                那么ServiceB.methodB就要抛出异常了。
     
                7: PROPAGATION_NESTED
                理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是,PROPAGATION_REQUIRES_NEW另起一个事务,将会与他的父事务相互独立,
                而Nested的事务和他的父事务是相依的,他的提交是要等和他的父事务一块提交的。也就是说,如果父事务最后回滚,他也要回滚的。
                而Nested事务的好处是他有一个savepoint。

     

     五种隔离级别
            isolation_default   这是一个platfromtransactionmanager默认的隔离级别,使用数据库默认的事务隔离级别.另外四个与jdbc的隔离级别相对应;
            isolation_read_uncommitted  这是事务最低的隔离级别,它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读,不可重复读和幻像读。
            isolation_read_committed    保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现,但是可能会出现不可重复读和幻像读。
            isolation_repeatable_read   这种事务隔离级别可以防止脏读,不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外,还保证了避免下面的情况产生(不可重复读)。
            isolation_serializable      这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读,不可重复读外,还避免了幻像读。