Spring框架(事务ACID特性)

目录,更新ing,学习Java的点滴记录

  目录放在这里太长了,附目录链接大家可以自由选择查看--------Java学习目录

Spring知识

  一丶SpringIOC初步认识↓↓↓
第一篇---->初识Spring
  二丶SpringIOC深入↓↓↓
第二篇---->深入SpringIoC容器(一)
第三篇---->深入SpringIoC容器(二)
  三丶装配SpringBean↓↓↓
第四篇---->依赖注入的方式
第五篇---->基于xml装配Bean
第六篇---->基于注解装配Bean
第七篇---->Spring Bean之间的关系
第八篇---->SpringBean的作用域
第九篇---->Spring 加载属性(properties)文件
第十篇---->Spring表达式(SpEL)
第十一篇---->Spring在xml中配置组件扫描
  四丶面向切面编程↓↓↓
第十二篇—>认识SpringAOP及底层原理
第十三篇—>使用@AspectJ注解开发AOP
第十四篇—>使用xml配置开发AOP
  五丶Spring中数据库编程↓↓↓
第十五篇—>数据库编程JdbcTemplate
  六丶Spring事务管理↓↓↓
第十六篇—>Spring事务管理初识
第十七篇—>编程式事务和声明式事务
第十八篇—>事务ACID特性
第十九篇—>事务传播行为
第二十篇—>事务隔离级别

6 事务----ACID特性

6.1 事务ACID特性

6.1.1 概念说明

• 数据库事务正确执行的4个基础要素是原子性(Atomicity),一致性(Consistency),隔离性(Isolation)和持久性(Durability)
• 原子性(atomicity): 事务是一个原子操作, 由一系列动作组成. 事务的原子性确保动作要么全部完成,要么全部失败,不会保持在中间某个环节.事务在执行过程中出现错误或者异常,会被回滚到事务开始前的状态,就像这个事务从来没有被执行过一样.
• 一致性(consistency): 数据和资源处于一种满足业务规则的一致性状态中.或者说事务可以改变封装的状态(除非他是只读事务),事务必须让数据库从一种一致性状态转换到另一种一致性状态,一个事务执行前后都必须处于一致性状态.
• 隔离性(isolation): 隔离性是当多个用户并发访问数据库时,数据库为每一个用户开启的事务,多个事务可能会同时处理相同的数据,隔离性就可以做到控制多个事务之间的隔离程度
• 持久性(durability): 一旦事务完成, 无论发生什么系统错误, 它的结果都不应该受到影响. 通常情况下, 事务的结果被写到数据库中,并不会回滚.

6.1.2 使用案例阐明ACID及其关系

• 案例:使用一个访问和跟新账户的事务集合构成的简单银行应用来阐明事务的概念,首先约定下面两个操作
    read(X):从数据库中把数据X读取出来,并保存在名称为X的变量中
    wirte(X):将X数据写回到数据库中
• 设事务T是从账户A转账50到账户B的的事务,现在给这个事务进行定义:
    
• 一致性:
    在这里,.一致性要求事务的执行不改变A和B之和.如果没有一致性的要求,金额可能会被事务凭空创造或者销毁.容易验证,如果数据库在事务执行前是一致的,那么事务执行后数据库仍将保持一致.
    确保单个事务的一致性是编写事务的开发人员的责任.完整性约束的自动检查会给工作带来便利.完整性约束可以保证授权用户对数据库所做的修改不会破坏数据的一致性.因此,完整性约束防止的是对数据的意外破坏.如name不能为null,任意两个人不能有相同id等等
• 原子性:
    假设事务T执行前,账户A有1000,账户B有2000.假设在事务T执行时系统出现故障,导致了T的执行没有成功完成.进一步假设故障发生在write(A)操作执行之后write(B)操作执行之前.在这种情况下,数据库反映出来的是A有950,B有2000.这次故障导致系统丢失了50.同时A+B的和不再维持原状.
    这样由于故障,系统的状态不再反映数据库本应描述的现实世界的真实状态,而是出于一种不一致状态.我们要做的就是保证这种不一致状态在数据库系统中是不可见的.但是,请注意,系统必然会在某一时刻出于不一致状态.即使事务T能执行完,也仍然存在某一时刻账户A的金额是950,而账户B的金额是2000,这显然是一个不一致状态.然而这一状态最终会被账户A的金额是950且账户B的金额是2050这个一致状态代替.这样,如果一个事务或者不开始,或者保证完成,那么这样的一个不一致状态除了在事务执行当中,在其他时刻是不可见的.这就是需要原子性的原因:如果具有原子性,某个事务的所有动作要么在数据库中全部反映出来,要么全部不反映.
    保证原子性的基本思路如下:对于事务要执行写操作的数据项,数据库系统在磁盘上记录好其旧值.这个信息记录在一个称为日志的文件中.如果事务没能完成它的执行,数据库系统从日志中恢复旧值,使得看上去事务从来没有执行过.保证原子性是数据库系统自身的责任.
• 持久性:
    一旦事务成功的完成执行,并且发起事务的用户已经被告知资金转账已经发生,系统就必须保证任何系统故障都不能引起与这次转账相关的数据丢失.持久性保证一旦事务成功完成.该事务对数据库所做的所有更新都是持久的,即使事务执行完成后出现系统故障.
• 隔离性:
    如果几个事务并发地执行,即使每个事务都能确保一致性和原子性,他们的操作会以人们所不希望的某种方式交叉执行,这也会导致不一致的状态.
    例如,在A->B转账的事务执行过程中,当A的总金额减少了50之后并且执行完了write操作,而B中总金额已经加上了50,但是还没有执行write操作时,数据库暂时是不一致的.如果另一个并发事务在这个中间时刻读取A和B的值并计算A+B,他将会的到不一致的值.更进一步,如果第二个事务基于它读取的不一致的值对A和B进行更新,及时两个事务都完成了,数据库仍可能处于不一致状态.
    一种避免事务并发执行而产生各种问题的方式是串行的执行事务----一个接一个的执行.但是这样会大大减低性能,其实还有很多方式可以允许事务并发执行但也能保证安全操作.
    事务的隔离性确保事务并发执行后的系统状态与这些事务以某种次序挨个执行后的状态是等价的.