一、事务简介

事务管理是企业级应使用程序开发中必不可少的技术, 使用来确保数据的完整性和一致性.

事务就是一系列的动作, 它们被当做一个单独的工作单元. 这些动作要么一律完成, 要么一律不起作使用

事务的四个关键属性(ACID)

（1）原子性(atomicity): 事务是一个原子操作, 由一系列动作组成. 事务的原子性确保动作要么一律完成要么完全不起作使用.

（2）一致性(consistency): 一旦所有事务动作完成, 事务就被提交. 数据和资源就处于一种满足业务规则的一致性状态中.

（3）隔离性(isolation): 可可以有许多事务会同时解决相同的数据, 因而每个事物都应该与其余事务隔离开来, 防止数据损坏.

（4）持久性(durability): 一旦事务完成, 无论发生什么系统错误, 它的结果都不应该受到影响. 通常情况下, 事务的结果被写到持久化存储器中.

二、事务管理的问题

必需为不同的方法重写相似的样板代码

这段代码是特定于 JDBC 的, 一旦选择类其它数据库存取技术, 代码需要作出相应的修改

三、Spring 中的事务管理

作为企业级应使用程序框架, Spring 在不同的事务管理 API 之上定义了一个笼统层. 而应使用程序开发人员不必理解底层的事务管理 API, 即可以用 Spring 的事务管理机制.

Spring 既支持编程式事务管理, 也支持公告式的事务管理.

编程式事务管理: 将事务管理代码嵌入到业务方法中来控制事务的提交和回滚. 在编程式管理事务时, 必需在每个事务操作中包含额外的事务管理代码.

公告式事务管理: 大多数情况下比编程式事务管理更好使用. 它将事务管理代码从业务方法中分离出来, 以公告的方式来实现事务管理. 事务管理作为一种横切关注点, 能通过 AOP 方法板块化. Spring 通过 Spring AOP 框架支持公告式事务管理.

四、Spring 中的事务管理器

Spring 从不同的事务管理 API 中笼统了一整套的事务机制. 开发人员不必理解底层的事务 API, 即可以利使用这些事务机制. 有了这些事务机制, 事务管理代码就可以独立于特定的事务技术了.

Spring 的核心事务管理笼统是TransactionManager，它为事务管理封装了一组独立于技术的方法. 无论用 Spring 的哪种事务管理策略(编程式或者公告式), 事务管理器都是必需的.

五、Spring 中的事务管理器的不同实现

（1）在应使用程序中只要要解决一个数据源, 而且通过 JDBC 存取

（2）在 JavaEE 应使用服务器上使用 JTA(Java Transaction API) 进行事务管理

（3）使用 Hibernate 框架存取数据库

（4）事务管理器以普通的 Bean 形式公告在 Spring IOC 容器中

六、事务准备

（1）准备数据库

（2）编写程序

（3）数据的变化如下

（4）假如在执行一次

抛出异常，余额不足！

账号余额没有改变

但是库存减少了

七、使用事务通知公告式地管理事务

事务管理是一种横切关注点

为了在 Spring 2.x 中启使用公告式事务管理, 能通过 tx Schema 中定义的<tx:advice>元素公告事务通知, 为此必需事前将这个 Schema 定义增加到根元素中去.

公告了事务通知后, 就需要将它与切入点关联起来. 因为事务通知是在<aop:config>元素外部公告的, 所以它无法直接与切入点产生关联. 所以必需在 <aop:config> 元素中公告一个加强器通知与切入点关联起来.

因为 Spring AOP 是基于代理商的方法, 所以只可以加强公共方法. 因而, 只有公有方法才可以通过 Spring AOP 进行事务管理.

八、使用 @Transactional 注解公告式地管理事务

除了在带有切入点, 通知和加强器的 Bean 配置文件中公告事务外, Spring 还允许简单地使用 @Transactional 注解来标注事务方法.

为了将方法定义为支持事务解决的, 能为方法增加 @Transactional 注解. 根据 Spring AOP 基于代理商机制, 只可以标注公有方法.

能在方法或者者类级别上增加 @Transactional 注解. 当把这个注解应使用到类上时, 这个类中的所有公共方法都会被定义成支持事务解决的.

在 Bean 配置文件中只要要启使用 <tx:annotation-driven> 元素, 并为之指定事务管理器即可以了.

?假如事务解决器的名称是 transactionManager, 即可以在 <tx:annotation-driven> 元素中省略 transaction-manager 属性. 这个元素会自动检测该名称的事务解决器.

再次执行

数据库没有任何变化

九、事务传播属性

当事务方法被另一个事务方法调使用时, 必需指定事务应该如何传播. 例如: 方法可可以继续在现有事务中运行, 也可可以开启一个新事务, 并在自己的事务中运行.

事务的传播行为能由传播属性指定. Spring 定义了 7? 种类传播行为.

十、需求

新定义 Cashier 接口: 表示用户的结账操作

修改数据表信息如下, 目的是使用户 Tom 在结账时, 余额只可以支付第一本书, 不够支付第二本书：

（1）REQUIRED 传播行为

当 bookService 的 purchase() 方法被另一个事务方法 checkout() 调使用时, 它默认会在现有的事务内运行. 这个默认的传播行为就是 REQUIRED. 因而在 checkout() 方法的开始和终止边界内只有一个事务. 这个事务只在 checkout() 方法结束的时候被提交, 结果使用户一本书都买不了

事务传播属性能在 @Transactional 注解的 propagation 属性中定义

（2）REQUIRES_NEW 传播行为

另一种常见的传播行为是 REQUIRES_NEW. 它表示该方法必需启动一个新事务, 并在自己的事务内运行. 假如有事务在运行, 就应该先挂起它.

代码实现：

再执行一次，数据还是没变

用REQUIRES_NEW 的传播行为

再次执行，只买了一本成功

十二、并发事务所导致的问题

当同一个应使用程序或者者不同应使用程序中的多个事务在同一个数据集上并发执行时, 可可以会出现许多意外的问题

并发事务所导致的问题能分为下面三种类型:

脏读: 对于两个事物 T1, T2, T1? 读取了已经被 T2 升级但 还没有被提交的字段. 之后, 若 T2 回滚, T1读取的内容就是临时且无效的.

不可重复读:对于两个事物 T1, T2, T1? 读取了一个字段, 而后 T2 升级了该字段. 之后, T1再次读取同一个字段, 值就不同了.

幻读:对于两个事物 T1, T2, T1? 从一个表中读取了一个字段, 而后 T2 在该表中插入了少量新的行. 之后, 假如 T1 再次读取同一个表, 就会多出几行.

十三、事务的隔离级别

从理论上来说, 事务应该彼此完全隔离, 以避免并发事务所导致的问题. 然而, 那样会对性可以产生极大的影响, 由于事务必需按顺序运行.

在实际开发中, 为了提升性可以, 事务会以较低的隔离级别运行.

事务的隔离级别能通过隔离事务属性指定

Spring 支持的事务隔离级别

事务的隔离级别要得究竟层数据库引擎的支持, 而不是应使用程序或者者框架的支持.

Oracle 支持的 2 种事务隔离级别：READ_COMMITED , SERIALIZABLE

Mysql 支持 4 中事务隔离级别.

设置隔离事务属性

使用 @Transactional 注解公告式地管理事务时能在 @Transactional 的 isolation 属性中设置隔离级别.

设置回滚事务属性

默认情况下只有未检查异常(RuntimeException和Error类型的异常)会导致事务回滚. 而受检查异常不会.

事务的回滚规则能通过 @Transactional 注解的 rollbackFor 和 noRollbackFor 属性来定义. 这两个属性被公告为 Class[] 类型的, 因而能为这两个属性指定多个异常类.

rollbackFor😕 遇到时必需进行回滚

noRollbackFor: 一组异常类，遇到时必需不回滚

库存减1了

余额没变

超时和只读属性

因为事务能在行和表上取得锁, 因而长事务会占使用资源, 并对整体性可以产生影响.

假如一个事物只读取数据但不做修改, 数据库引擎能对这个事务进行优化.

超时事务属性: 事务在强制回滚之前能保持多久. 这样能防止长期运行的事务占使用资源.

只读事务属性: 表示这个事务只读取数据但不升级数据, 这样能帮助数据库引擎优化事务.

超时和只读属性能在 @Transactional 注解中定义.超时属性以秒为单位来计算.

十四、用XML文件的方式配置事务