Spring事务一：事务的原子性控制以及事务传播特性：
 
我们学习的AOP，最重要的就是对事务的控制。
 
实际项目中，对数据库的单次操作，如一次insert，我们在jdbc Template中，使用的是jdbc的事务，会自动的为我们提交事务。但是在实际项目中，一次操作可能会涉及多次数据库的连接，这样是需要我们来保证事务的一致性的，要么同时成功，要么同时失败，使用jdbc实现起来是很麻烦的，使用AOP就可以来完成这些工作。如我单次操作，多次数据库的连接，AOP可以自动的来为我开启事务，关闭事务，提交事务，包括事务的传播特性，隔离级别，都可以使用AOP来做设置。
 
 
 
事务我们自己去写，是一件很麻烦的事情，事务的传播，隔离级别，自己去写的话是相当费事的，使用Spring的AOP可以简单很多。
 
 
 
1：事务的概述和特征：
 
1：什么是事务：
 
一荣俱荣，一损俱损，多个复杂的操作，可以将其看作是一个整体，要么同时成功，要么同时失败。
 
事务的四个特征（ACID）：
 
这四个特征面试常问，工作中也是很重要的。
 
 
 
 
 
原子性（Atomic）：表示组成一个事务的多个数据库的操作是不可分割的单元。只有所有的操作成功，才算成功，整个事务提交的时候，其中任何一个操作失败，都会导致所有操作失败，那么事务就会做回滚。
如我一次事务中，有十次对数据库的操作，这十次操作要么同时成功，要么同时失败。一个操作失败，即这十个操作全部失败。
 
 
 
一致性（Consistentcy）：事务操作成功后，数据库所处的状态和业务规则保持一致。
 
 
如A转100元给B，就要保证A的账户减少100元，B的账户增加100元。转账前后，A和B账户的余额是不会有变化的。如果A减少了100元，但是B却没有增加100元，这样就是不一致的。
 
 
 
隔离性（islation）:多个数据库的操作，操作相同的数据并发时，不同的事务有自己的数据空间，事务与事务之间不受干扰。
 
 
但是不是完全不受干扰，干扰程度由数据库或者操作事务的隔离级别来决定的，隔离级别越高，干扰就越低，并发性就越低，数据的一致性越好。
 
 
 
持久性（Druability）:一旦事务提交成功，数据就持久化到数据库之中了，是不可以在回滚了。重启机器，重启服务器，数据都还是在的。
 
 
原子性：可以使用Spring的事务传播来控制，一致性和隔离性：使用数据库的隔离级别来控制
 
 
 
 
 
2：事务原子性剖析：
 
Spring中，原子性的控制主要体现在事务传播这一块（Spring对事物传播特性的控制）。
 
现在我来建立两张表：订单表和订单明细表，订单明细表中添加订单表的主键，但是不使用约束：
 
 
 
 
 
 
 
1：使用注解来处理事务传播特性：
 
说明：我们要保证事务的原子性，通过@Transational注解。使用这个注解之前，我必须要在Spring的配置文件中，开启事务注解的驱动。
 
 
 
第一步：配置事务管理器，开启注解的事务的启动
 
 
 
 
 
 
 
 
 
 
 
 
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-3.2.xsd
           http://www.springframework.org/schema/tx
           http://www.springframework.org/schema/tx/spring-tx-3.2.xsd">
<!-- 从属性文件中读取数据源 
那么我下面对数据源的配置，value中使用值的形式，就和el表达式得语法差不多
-->
<context:property-placeholder location="classpath:jdbc.properties"/>
           
<!-- 配置dbcp的数据源
destroy-method:一旦数据源调用了close方法，会做资源的销毁，连接的释放
 -->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
   <!-- 配置Mysql的驱动  com.mysql.jdbc.Driver-->
   <property name="driverClassName" value="${driverClassName}"></property>
   <!-- 配置url  jdbc:mysql://localhost:3306/[database]-->
   <property name="url" value="${url}"></property>
   <!-- 配置username -->
   <property name="username" value="${uname}"></property>
   <!-- 配置password -->
   <property name="password" value="${pword}"></property>
   <!-- 数据源加载的时候，自动的为我创建多少个连接，之后我使用的时候，就不用临时创建了，直接使用就可以了 -->
   <property name="initialSize" value="${initialSize}"></property>
   <!-- 数据库连接池中最大创建的连接数的配置，这里是最大为我创建5个连接，我如果一次使用了5个连接，连接池就不会再来为我创建了，
   就只能通过jdbc来创建
    -->
   <property name="maxActive" value="${maxActive}"></property>
   <!-- 最大空闲连接数 ，如果有多余的空闲连接，这个连接是会被释放的，也就是销毁-->
   <property name="maxIdle" value="${maxIdle}"></property>
   <!-- 最小空闲连接数：我连接闲置的时候，也不能全部都释放，一定要有闲置的连接，以便于有请求过来的时候，可以使用 -->
   <property name="minIdle" value="${minIdle}"></property>
   
<!-- 数据源配置完毕后，就可以来访问数据库了，
这里接着配置的话，可以使用配置文件的方式，也可以使用注解的方式，使用注解方式的话，就要配置注解扫描器，
使用配置文件方式的话，就将Bean全部配置在配置文件中，进行管理，现在使用配置文件的方式。
 -->
</bean>

<!-- 为orderDao的实现类来创建Bean -->
<bean id="orderDao" class="cn.aa.spring.dao.impl.orderDaoImpl">
  <!-- 为Bean注入数据源，由于我的数据源，是在Bean中定义了属性的，所以，我可以通过下面的方式来做 -->
  <property name="dataSource" ref="dataSource"></property>
</bean>

<!-- 为detailDao的实现类来创建Bean -->
<bean id="detailDao" class="cn.aa.spring.dao.impl.DetailDaoImpl">
  <!-- 为Bean注入数据源，由于我的数据源，是在Bean中定义了属性的，所以，我可以通过下面的方式来做 -->
  <property name="dataSource" ref="dataSource"></property>
</bean>
<!-- 为UserServiceImpl来创建Bean -->
<bean id="orderService" class="cn.aa.spring.service.impl.OrderServiceImpl">
  <property name="orderDao" ref="orderDao"></property>
  <property name="detailDao" ref="detailDao"></property>
</bean>


<!-- 创建事务管理器，在Bean中创建
class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
设置事务管理器，Spring是为我们提供了事务管理器的。这个事务管理器，就是用来管理事务的，可以让我的事务保持事务的四个特征，也就是ACID。-->

<bean id="lbj" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

  <!-- 注入数据源，为什么要注入数据源：DataSourceTransactionManager是依赖于数据库的，它有很多的特性，都是依赖于数据库的，像数据库的隔离级别等等。-->
   <property name="dataSource" ref="dataSource"></property>

</bean>

<!-- 事务管理器配置好之后，首先使用注解的形式来对事务进行管理：开启注解的事务驱动，transaction-manager="transactionManager":关联事务管理器，事务管理器是我们的核心。使用annotation-driven只是使用这种注解，标注在目标的类，或者方法上，真正管理事务的还是事务管理器
 -->
<tx:annotation-driven transaction-manager="lbj"/>
 
第三步：通过@Transational注解来标志要使用事务的类或接口或方法。
 
多数情况是标注在类上面，或者方法上面，其实我们也是建议标注在类或者方法上面。如果我需要控制的力度很细的话，就标注在方法上面，如果一个类都采用同一种方式，来做事务的传播，或者隔离级别，就标注在类上面。
 
接口上面为什么一般不标注：
 
标注在接口上，接口的使用一般是通过实现类的，注解是不会被实现类继承的。
 
标注在方法上面，可以让我们控制的更为细一些，@Transational注解 可以来设置我们的事务的传播。
 
 
 
在实际项目中，我们通常将事务开启在service层。
 
 
 
现在假设我没有使用注解的情况
 
 
 
 
 
 
 
 
 
2：原子性刨析：
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
以上的话，显然是有问题的，没有保证事务的一致性，这种情况显然是不允许的。在实际项目中，一定不能发生这种情况，这是非常严重的错误。现在我来进行解决：
 
 
 
实例代码：使用Transactional标注要使用事务的方法：
 
public class OrderServiceImpl implements OrderService{
	
	private OrderDao orderDao;
	
	private DetailDao detailDao;
	
	
public void setOrderDao(OrderDao orderDao) {
		this.orderDao = orderDao;
	}
    
	public void setDetailDao(DetailDao detailDao) {
		this.detailDao = detailDao;
	}
    /*
     * 
     * 使用@Transactional注解，来保证事务的一致性
     * rollbackFor=Exception.class:发生这个非运行期异常的时候，做回滚。
*/
@Transactional(rollbackFor=Exception.class)
@Override
public void saveOrderAntDetail(Order order, Detail detail){

/*我的detailDao其实引用了orderDao中的主键，我们其实应该将orderDao保存之后，将其主键返回回来，然后再设置给detailDao，这样才可以保证完整性
*/
		//首先插入一条数据到订单表，然后获得我插入数据的id
		Integer orderId = orderDao.saveOrder(order);
		
		/*
		 * 现在我没有使用注解标注，假如发生了异常
		 */
		
		//将订单表的id设置给明细表
		detail.setOrderId(orderId);
		//插入一条数据到明细表
		detailDao.saveDetail(detail);
		//int i = 1/0;
		/*
		 * 现在我在这里，要保证事物的原子性，这两个操作要么同时成功，要么同时失败。假如我订单保存成功了，但是明细没有保存成功，那么我的订单就是一个脏数据，这个订单就是一个废的。就没有意义。所以这两个操作要么同时成功，要么同时失败。
		 */
		
		
		//throw new Exception();
		
		
	}
	
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
注意：在Service层开启事务的时候，默认情况下，发生运行是异常会做回滚，非运行时异常不会做回滚。
 
 
 
 
 
 
对于非运行期异常，默认情况下是不做回滚，但是我们可以对其进行设置，让其做回滚。
 
但是我们可以通过@Transaional中的属性进行设置，对那个异常做回滚，对那个异常不做回滚。但是在实际工作中，一般不会设置，实际工作中，一般也是对运行期异常来做回滚。
 
非运行期异常是需要我们来处理的。
 
 
 
 
 
 
关于事务默认的传播特性：
 
 
public class OrderServiceImpl implements OrderService{
 
   
 
    private OrderDao orderDao;
 
   
 
    private DetailDao detailDao;
 
   
 
   
 
 
 
    public void setOrderDao(OrderDao orderDao) {
 
        this.orderDao = orderDao;
 
    }
 
 
 
 
 
 
 
    public void setDetailDao(DetailDao detailDao) {
 
        this.detailDao = detailDao;
 
    }
 
    /*
 
     * 我通过Transational保证了事务的原子性 ，原子性的保证，是由事务的传播特性来控制的。Transational:的默认的事务传播特性是required。在实际项目中，百分之八十都是required。当下面这个方法执行的时候，Spring会开启事务，开启的是一个事务。下面两个操作，使用的是同一个事务。我们默认情况下，使用的是required,就是不管我这里有多少个操作，使用的都是同一个事务，也就是说，这个事务会按着操作的执行顺序，往下面传递。这样就使得我所有的操作，在一个事物之中，一荣俱荣，一损俱损。所有的操作要么同时成功，要么同时失败。@Transactional(propagation=):来进行传播特性的设置，
 
     */
 
 
 
    @Transactional
 
    @Override
 
    public void saveOrderAntDetail(Order order, Detail detail){
 
        Integer orderId = orderDao.saveOrder(order);
 
        detail.setOrderId(orderId);
 
        detailDao.saveDetail(detail);
 
    }
 
   
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

  服务化之后，事务一致性需要得到保证。具体要视业务场景选择合适的方案保证事务的一致性。
 
  数据库事务的ACID特性，分别含义如下：
 
  A:  指原子性，即一个事务下的n个复合操作，要么全部成功，要么全部失败。
 
  c：指的是一致性，即要求事务做完后，要求满足数据库的一些完整性约束，如：记录的主键约束。从业务层理解是：A帐户转钱给B帐户100元钱，这时数据库事务就必须保证A帐户钱减100,B帐户加100,且最终a,b帐户余额也是正确的。
 
 i： 指的隔离性，指的是一个事务未提交的业务结果是否对于其它事务可见。级别一般有：read_uncommit，read_commit，read_repeatable，串行化访问。
 
 d：指的是持久性。即事务操作完后，事务的结果应该是持久化的。
 

 
 
  传统数据库，如mysql，oracle一般采用日志来保证事务的acid特性。事务acid在单个数据库时比较容易满足。即只要将a,b,c三个业务操作放在一个事务中执行，之后的acid特性由数据库底层保证。
 

 
 
  而当服务化后，多个业务操作会涉及多台服务器，多个数据库存储。这就需要有相应的手段保证业务操作在多个数据库中的一致性。
 
  分布式服务事务比较有名的cap理论，提供了一种在分布式服务中事务设计的一种思路。
 
  cap理论中的c指的是，从任意多个结点（如多个数据库），它们上面的数据副本应该是一致的。a指的是对于［更新数据的服务］的可用性。
 
  p指的是分区的情况。
 
 简单来讲cap指的是无法同时满足cap三者。这样在有p分区的情况下，需要我们在c和a间做一个平衡。
 
 
 
  举例来讲，电商中，要购买一件产品，假设有：Ａ操作－扣除产品份额，b操作－支付扣用户帐户钱，c操作将产品加到用户资产。
 
  这个就是典型的一种分布式服，由于a,b,c操作分别调用三个服务。而当操作a，b, c时都可能发生网络超时会数据库等错误。这样会导致a,b,c操作会处于不一致状态。
 
  如a操作－扣款产品份额成功，b操作超时，这时就发生了分区的情况。因为b操作－支付可能成功也可能失败，此时系统已经发生不一致的情况。
 
  此时我们一般使用事务补偿机制来做，即后台一个线程会扫描此笔交易，发现b支付操作如果成功，则更新订单为成功，做c操作。
 
  如果b支付操作失败，则回滚a操作。
 
  如果b支付操作为操作中，则回滚a操作产品扣份额。此笔订单之后再做处理。直到明确得到支付结果再执行正向提交操作，或逆向回滚操作。
 

 
 

 

ACID
 ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
 原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
 一致性：一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。
 隔离性：如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。
 持久性：在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

事务的概念
 
事务是访问并可能更新各种数据项的一个程序执行单元。
 
事务的特性（ACID 特性）
 
原子性（atomicity）：事务的所有操作在数据库中要么全部反映出来，要么完全不反映。
 
一致性（consistency）：隔离执行事务时（换言之，在没有其他事务并发执行的情况下）保持数据库的一致性。
 
隔离性（isolation）：尽管多个事务可能并发执行，但系统保证，对于任何一对事务Ti和Tj，在Ti看来，Tj或者在Ti开始之前已经完成执行，或者在Ti完成之后开始执行。因此，每个事务都感觉不到系统中有其他事务在并发执行。
 
持久性（durability）：一个事物成功完成后，它对数据库的改变必须是持久的，即使出现系统故障。
 
事务隔离性级别
 
SQL标准规定的隔离性级别
 
可串行化（serializable）：通常保证可串行化调度。然而，一些数据库系统对该隔离性级别的实现在某些情况下允许非可串行化执行。最高隔离性级别。强制事务串行执行。可避免脏读、不可重复读、幻读的发生。
 
可重复读（repeatable read）：只允许读取已提交数据，而且在一个事务两次读取一个数据项期间，其他事务不得更新该数据。但该事务不要求与其他事务可串行化。例如：当一个事务在查找满足某些条件的数据时，它可能找到一个已提交事务插入的一些数据，但可能找不到该事务插入的其他数据。保证在同一个事务中多次读取同样数据的结果是一样的。可避免脏读、不可重复读的发生。
 
已提交读（read committed）：只允许读取已提交数据，但不要求可重复读。比如，在事务两次读取一个数据项期间，另一个事务更新了该数据并提交。一个事务只能读取已经提交的事务所做的修改。换句话说，一个事物所做的修改在提交之前对其他事务是不可见的。可避免脏读的发生。
 
未提交读（read uncommitted）：允许读取未提交数据。这是SQL允许的最低一致性级别。事务中的修改，即使没有提交，对其他事务也是可见的。最低级别，任何情况都无法保证。
 
以上所有隔离性级别都不允许脏写（dirty write），即如果一个数据项已经被另外一个尚未提交或中止的事务写入，则不允许对该数据项执行写操作。
 
许多数据库系统运行时的默认隔离性级别是已提交读。在SQL中，除了接受系统的默认设置，还可以显式地设置隔离性级别。例如，语句“set transaction isolation level serializable;”将隔离性级别设置为可串行化，其他隔离性级别可类似设定。
 
修改隔离性级别必须作为事务的第一条语句执行。此外，如果单条语句的自动提交默认打开，则必须关闭。