事务四个属性ACID
-  
原子性(atomicity)
事务是原子性操作,由一系列动作组成,事务的原子性确保动作要么全部完成,要么完全不起作用 -  
一致性(consistency)
一旦所有事务动作完成,事务就要被提交。数据和资源处于一种满足业务规则的一致性状态中 -  
隔离性(isolation)
可能多个事务会同时处理相同的数据,因此每个事务都应该与其他事务隔离开来,防止数据损坏 -  
持久性(durability)
事务一旦完成,无论系统发生什么错误,结果都不会受到影响。通常情况下,事务的结果被写到持久化存储器中 
举例说明
- 在我的代码中有查询用户好添加用户删除用户的方法,比如我的查询语句写的有错误 如下
 
<delete id="deleteUser" parameterType="user">
        deletes from test where id=#{id}
    </delete>
 
- 在查询用户方法中,我调用了增加一个用户和删除一个人用户的方法如下代码
 
public class userMapperImpl extends SqlSessionDaoSupport implements userMapper{
    @Override
    public List<User> selectUser() {
        userMapper userMapper=getSqlSession().getMapper(com.xu.mapper.userMapper.class);
        userMapper.addUser(new User(31,"haha",21));
        userMapper.deleteUser(3);
        return getSqlSession().getMapper(userMapper.class).selectUser();
    }
    @Override
    public int addUser(User user) {
        System.out.println(getSqlSession().getMapper(userMapper.class).addUser(user));
        return getSqlSession().getMapper(userMapper.class).addUser(user);
    }
    @Override
    public int deleteUser(int id) {
        return getSqlSession().getMapper(userMapper.class).deleteUser(id);
    }
}
 
这样执行的结果是:一个用户会被添加到数据库中,同时程序报错,这是我们不希望看到的,在我们对事物的理解中,事物要么被全部完成,要么就不起作用。
spring中的事务管理
Spring在不同的事务管理API之上定义了一个抽象层,使得开发人员不必了解底层的事务管理API就可以使用Spring的事务管理机制。Spring支持编程式事务管理和声明式的事务管理。
-  
编程式事务管理
将事务管理代码嵌到业务方法中来控制事务的提交和回滚
缺点:必须在每个事务操作业务逻辑中包含额外的事务管理代码 -  
声明式事务管理
一般情况下比编程式事务好用。
将事务管理代码从业务方法中分离出来,以声明的方式来实现事务管理。
将事务管理作为横切关注点,通过aop方法模块化。Spring中通过Spring AOP框架支持声明式事务管理。 
事务管理器
-  
无论使用Spring的哪种事务管理策略(编程式或者声明式)事务管理器都是必须的。
 -  
就是 Spring的核心事务管理抽象,管理封装了一组独立于技术的方法。
 
举例
- jdbc事务
 
<!--jdbc事物-->
   <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="add" propagation="REQUIRED"/>
     <tx:method name="delete" propagation="REQUIRED"/>
     <tx:method name="update" propagation="REQUIRED"/>
     <tx:method name="search*" propagation="REQUIRED"/>
     <tx:method name="get" read-only="true"/>
     <tx:method name="*" propagation="REQUIRED"/>
 </tx:attributes>
</tx:advice>
 
- 配置AOP使用AOP切入
 
   <aop:config>
        <aop:pointcut id="txPointcut" expression="execution(* com.xu.mapper.*.*(..))"/>
        <aop:advisor advice-ref="txAdvice" pointcut-ref="txPointcut"/>
    </aop:config>
 
这样的话我们再去测试就不会出现刚才的问题,增加用户方法不会被执行,保证了数据的一致性
PS:
 spring事务传播特性:
事务传播行为就是多个事务方法相互调用时,事务如何在这些方法间传播。spring支持7种事务传播行为:
propagation_requierd:如果当前没有事务,就新建一个事务,如果已存在一个事务中,加入到这个事务中,这是最常见的选择。
propagation_supports:支持当前事务,如果没有当前事务,就以非事务方法执行。
propagation_mandatory:使用当前事务,如果没有当前事务,就抛出异常。
propagation_required_new:新建事务,如果当前存在事务,把当前事务挂起。
propagation_not_supported:以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
propagation_never:以非事务方式执行操作,如果当前事务存在则抛出异常。
propagation_nested:如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与propagation_required类似的操作
 
Spring 默认的事务传播行为是 PROPAGATION_REQUIRED,它适合于绝大多数的情况。
假设 ServiveX#methodX() 都工作在事务环境下(即都被 Spring 事务增强了),假设程序中存在如下的调用链:Service1#method1()->Service2#method2()->Service3#method3(),那么这 3 个服务类的 3 个方法通过 Spring 的事务传播机制都工作在同一个事务中。










