在一个实际项目中事务都是由业务层进行管理的，因为业务逻辑上的一组操作才是实际意义上的事务。
_Spring的事务管理.png
数据库系统中有事务，Dao 层中也有事务，业务层中也有事务。三者范围如图所示
数据库的事务
由具体的数据库管理系统进行管理
_数据库的事务.png
事务的ACID特性
-
原子性：事务是一个不可分割的操作的集合 -
一致性：当事务完成时，必须使所有的数据都保持一直状态 -
隔离性：事务和事务之间不能互相干扰。这里的事务和线程就类似了，线程和线程之间也不应该互相干扰PROPAGATION_REQUIRED -
持久性：事务一旦提交，它在数据库中的改变就是永久性的
不考虑事务隔离性带来的问题
-
脏读：一个事务读到了另一个事务未提交的数据 -
不可重复读：一个事务读到了另一个事务已经提交的** update **的数据，导致在同一个事务中的多次查询结果不一致。也就是第一次读到数据 A ，第二次读到另一个事务更改后的数据 B ，导致两次读到的数据不同。 -
虚读：一个事务读到了另一个事务已经** insert **的数据，导致在同一个事务中的多次查询结果不一致。也就是第一次读到数据 A ，第二次读到另一个事务插入后的新数据 B ，导致两次读到的数据不同。
事务的隔离级别
为了避免造成上述的几种并发问题，在标准 SQL 规范中，定义了 4 个事务隔离级别，不同的隔离级别对事务的处理不同。
-
读未提交( Read Uncommitted ,1 级)：什么读问题解决不了 -
已提交读( Read committed ，2 级)：可以解决脏读问题，必须在事务提交后，才可读到数据 -
可重复读( Repeatable Read，4 级)：解决脏读和不可重复读，也就是在另一个事务进行update操作的时候，不能读数据 -
序列化/串行化( Serializable，8 级)：完全符合事务的 ACID 的隔离级别，但是效率很低。
事务的隔离级别是由数据库提供的保护机制，隔离级别越高，安全性就越高，但是效率就越低。
事务管理的API
Spring 中进行事务管理主要有三个接口
-
PlatformTransactionManager，平台事务管理器，是Spring用于管理事务的真正的对象。该接口有两个实现类如下-
DataSourceTransactionManager，底层使用 JDBC 管理事务 -
HibernateTransactionManager，底层使用 Hibernate 管理事务
-
-
TransactionDefinition，事务定义信息，用于定义事务的相关的信息，比如，隔离级别、超时信息、传播行为、是否只读等 -
TransactionStatus，事务的状态，用于记录在事务管理过程中，事务的状态的对象。
事务管理的 API 的关系：Spring 进行事务管理的时候，首先平台事务管理器根据事务定义信息进行事务的管理，在事务管理过程中，产生各种状态，将这些状态的信息记录到事务状态的对象中。
事务的传播行为
业务层中的方法是一个事务，但是很多时候，业务层中的方法也需要互相调用，这就带来了新的事务问题。
如何保证这种业务层方法互相调用产生的新的事务呢？这就是事务的传播行为所需要关心的问题。
Spring 中提供了七种事务的传播行为来解决此问题：
-
保证多个操作在同一个事务中
-
PROPAGATION_REQUIRED(90%情况下都用这个)：默认值，如果A中有事务，使用A中的事务(包起来)，如果A没有，创建一个新的事务，将操作包含进来 -
PROPAGATION_SUPPORTS：支持事务，如果A中有事务，使用A中的事务(包起来)。如果A没有事务，不使用事务。 -
PROPAGATION_MANDATORY：如果A中有事务，使用A中的事务(包起来)。如果A没有事务，抛出异常。
-
-
保证多个操作不在同一个事务中
-
PROPAGATION_REQUIRES_NEW：如果A中有事务，将A的事务挂起（暂停），创建新事务，只包含自身操作。如果A中没有事务，创建一个新事务，包含自身操作。 -
PROPAGATION_NOT_SUPPORTED：如果A中有事务，将A的事务挂起。不使用事务管理。 -
PROPAGATION_NEVER：如果A中有事务，报异常。
-
-
嵌套式事务
-
PROPAGATION_NESTED：嵌套事务，如果A中有事务，按照A的事务执行，执行完成后，设置一个保存点，执行B中的操作，如果没有异常，执行通过，如果有异常，可以选择回滚到最初始位置，也可以回滚到保存点。
-
确实有这么多种类型的事务传播行为，但是 Spring 中默认采用的是PROPAGATION_REQUIRED类型，总之它能实现的功能就是，即使业务层中的某个方法使用了其他的方法，也能够保证着不同的方法之间是一次原子操作。也就是用一个事务把这次操作涉及到的所有方法都当成是一个方法、一个事务看待。
声明式事务
Spring 框架如何在我们编写的代码的基础上添加事务控制的代码呢？更准确的说是在业务层的方法之前开启事务，在方法之后提交事务，并捕获可能发生异常，随时准备进行回滚操作呢？
这不就是典型的 AOP 问题吗？直接在业务层的方法之前添加前置通知，之后添加后置通知不就是了吗？Spring 的事务管理实现的底层机制就是 AOP 。如图所示
_Spring事务实现机制.png
Spring 框架中对事务的封装很完善，在实际配置中，如果没有特殊要求的话，可以配置一个完全通用的模板，保证业务层所有操作都是一个事务，非常的方便，配置也很简单。有以下几个步骤即可
XML 配置
第一步，配置数据源
<!-- 配置C3P0连接池-->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="driverClass" value="${jdbc.driverClass}"/>
<property name="jdbcUrl" value="${jdbc.url}"/>
<property name="user" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
第二步，配置事务管理器实现类
<!-- 配置事务管理器 -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
第三步，配置事务的规则，这里表示所有方法都采用默认的事务传播管理机制，即保证所有操作都是事务安全的
<!-- 配置事务的增强 -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<!-- 事务管理的规则 -->
<tx:method name="*" propagation="REQUIRED" read-only="false"/>
</tx:attributes>
</tx:advice>
第四步，AOP 的配置，指定切入点和事务管理机制
<!-- aop的配置 -->
<aop:config>
<aop:pointcut expression="execution(* com.itheima.tx.demo2.AccountServiceImpl.*(..))" id="pointcut1"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="pointcut1"/>
</aop:config>
注解的配置
第一步，配置数据源
<!-- 配置C3P0连接池-->
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="driverClass" value="${jdbc.driverClass}"/>
<property name="jdbcUrl" value="${jdbc.url}"/>
<property name="user" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
第二步，配置事务管理器实现类
<!-- 配置事务管理器 -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
第三步，开启注解事务
<!-- 开启注解事务 -->
<tx:annotation-driven transaction-manager="transactionManager"/>
第四步，在业务层的类中添加一个@Transactional注解即可
事务理解很简单，配置起来就更简单了。
网友评论