一、事务简介
事务管理是企业级应用程序开发中必不可少的技术，用来确保数据的完整性和一致性；
事务就是一系列的动作, 它们被当做一个单独的工作单元，这些动作要么全部完成，要么全部不起作用；
事务的四个关键属性(ACID)：
- 原子性(atomicity)：事务是一个原子操作，由一系列动作组成，事务的原子性确保动作要么全部完成要么完全不起作用；
- 一致性(consistency)：一旦所有事务动作完成，事务就被提交，数据和资源就处于一种满足业务规则的一致性状态中；
- 隔离性(isolation)：可能有许多事务会同时处理相同的数据，因此每个事物都应该与其他事务隔离开来，防止数据损坏；
- 持久性(durability)：一旦事务完成, 无论发生什么系统错误，它的结果都不应该受到影响，通常情况下，事务的结果被写到持久化存储器中
二、原始使用事务的问题
在我们学习JDBC的时候，最常见的实现业务的写法是：
Connection conn = null; try { conn = dataSource.getConnection(); conn.setAutoCommit(false); /** 执行业务方法 **/ conn.commit(); } catch (Exception e) { if(conn != null) { conn.rollback(); } } finally { if(conn != null) { conn.close(); } }
可以看出：
1.我们在写业务方法时，必须为不同的方法重写类似代码；
2.刚刚也说了，这是学JDBC时候经常用的写法来达到控制事务，那么如果我们还其它数据库存取方案，代码则需要大量做出修改。
三、Spring中的事务
作为企业级应用程序框架，Spring 在不同的事务管理 API 之上定义了一个抽象层，而应用程序开发人员不必了解底层的事务管理 API，就可以使用 Spring 的事务管理机制；
Spring 既支持编程式事务管理，也支持声明式的事务管理；
编程式事务管理：将事务管理代码嵌入到业务方法中来控制事务的提交和回滚，在编程式管理事务时，必须在每个事务操作中包含额外的事务管理代码；
声明式事务管理：大多数情况下比编程式事务管理更好用，它将事务管理代码从业务方法中分离出来，以声明的方式来实现事务管理，事务管理作为一种横切关注点，可以通过 AOP 方法模块化，Spring 通过 Spring AOP 框架支持声明式事务管理；
注意：声明式事务时基于AOP框架支持，所以我们大概能猜测得到，在执行业务方法之前，前置通知开启事务，执行业务方法之后后置通知提交事务，如果业务方法执行异常了那么异常通知回滚事务。
四、Spring中的事务管理器
Spring 从不同的事务管理 API 中抽象了一整套的事务机制，开发人员不必了解底层的事务 API，就可以利用这些事务机制，有了这些事务机制, 事务管理代码就能独立于特定的事务技术了；
Spring 的核心事务管理抽象是org.springframework.transaction Interface PlateformTransactionManager，它为事务管理封装了一组独立于技术的方法，无论使用 Spring 的哪种事务管理策略(编程式或声明式)，事务管理器都是必须的 !
其不同实现为：
org.springframework.jdbc.datasource Class DataSourceTransaction
在应用程序中只需要处理一个数据源, 而且通过 JDBC 存取
org.springframework.transaction.jta Class JtaTransactionManager
在 JavaEE 应用服务器上用 JTA(Java Transaction API) 进行事务管理
org.springframework.orm.hibernate3 Class HibernateTransactionManager
用 Hibernate 框架存取数据库
注意：事务管理器以普通的 Bean 形式声明在 Spring IOC 容器中
五、使用注解的方式声明式的管理事务
1.为方法添加 @Transactional 注解
2.根据 Spring AOP 基于代理机制，只能标注公有方法
3.在方法或者类级别上添加 @Transactional 注解，如果添加到类上，这个类中的所有公共方法都会被定义成支持事务处理
4.配置如下：
<!-- 配置 C3P0 数据源 --> <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"> <property name="user" value="${jdbc.user}" /> <property name="password" value="${jdbc.password}" /> <property name="jdbcUrl" value="${jdbc.jdbcUrl}" /> <property name="driverClass" value="${jdbc.driverClass}" /> <property name="initialPoolSize" value="${jdbc.initPoolSize}" /> <property name="maxPoolSize" value="${jdbc.maxPoolSize}" /> </bean> <!-- 配置事务管理器 --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" /> </bean> <!-- 启用事务注解 --> <tx:annotation-driven transaction-manager="transactionManager" />
注意：注解声明式事务是最常用的方式，建议使用注解声明式来控制事务，其它事务不再罗列。
六、事务的传播行为
当事务方法被另一个事务方法调用时, 必须指定事务应该如何传播.。比如方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行；
以下是Spring 支持的事务传播行为：
REQUIRED:调用方有事务在运行，被调用方的事务方法就在调用方的事务方法中运行；如果调用方没有事务，则新建事务在本身事务中运行；
REQUIRED_NEW:当前方法有事务在运行，被调用方的事务方法在它自己的事务内运行，调用方的事务方法被挂起，待被调用方的事务方法执行结束后继续；
SUPPORTS：支持当前事务，假设当前没有事务，就以非事务方式运行；
NOT_SUPPORTS：以非事务方式运行操作，假设调用方有事务在运行，就把当前事务挂起；
MANDATORY：调用方有事务在运行，被调用方的事务方法就在调用方的事务方法中运行；如果调用方没有事务，就抛出异常；
NEVER：以非事务方式运行，假设调用方有事务在运行，则抛出异常；
NESTED：如果调用方有事务方法在运行，被调用方应该在调用方事务的嵌套事务内运行，否则，就启动一个新的事务并在自己的事务内运行
注意：常用的是REQUIRED和REQUIRED_NEW，以下详细说明这两种事务传播行为 !
--->REQUIRED传播行为：以网上搜来的图为例来说明
说明：
1.在checkout这个方法内运行着事务，分别是TX1开始事务，TX1结束事务；
2.在本事务内，存在着被调用方，被调用方也运行着事务方法，从图中看，这可能是循环调用存在事务的purchase方法；
3.我们假设就是循环调用存在事务的purchase方法，那么以伪代码来体现：
@Transactional public void checkout() { // 执行批量购买 for(int i=0;i<10;i++) { purchase(i); } } @Transactional public void purchase(i) { System.out.println("购买了i="+i); }
4.进入checkout方法时开启事务，开始执行for循环时，purchase发现调用方方法checkout存在事务，则把自己也交给checkout事务管理；
5.一旦for循环执行purchase其中一个方法抛出异常，那么之前purchase执行成功都不算数，全部被回滚，这就体现了要么事务一起成功，要么一起失败。
说明：默认的事务时REQUIRED，即所有被调用的方法都是用调用方的事务，不再使用自身的事务。
效果：如果被调用方的方法一旦出现异常，那么所有被调用方执行的结果都被回滚。
--->REQUIRED_NEW传播行为：以网上搜来的图为例来说明
另一种常见的传播行为是 REQUIRES_NEW，它表示该方法必须启动一个新事务，并在自己的事务内运行，如果有事务在运行，就应该先挂起它
说明：
1.在checkout这个方法内运行着事务，分别是TX1开始事务，TX1结束事务；
2.在本事务内，存在着被调用方，被调用方也运行着事务方法，从图中看，这可能是循环调用存在事务的purchase方法；
3.我们假设就是循环调用存在事务的purchase方法，那么以伪代码来体现：
@Transactional public void checkout() { // 执行批量购买 for(int i=0;i<10;i++) { purchase(i); } } @Transactional public void purchase(i) { System.out.println("购买了i="+i); }
4.进入checkout方法时开启事务，开始执行for循环时，purchase发现调用方方法checkout存在事务，则把checkout方法的事务挂起，开始自己的事务；
5.假设当i=5的时候，执行抛出了异常，那么从i=0到i=4的这5次执行并不会被回滚，因为它是单独的一个事务，而i=5这次执行被回滚了。
效果：如果被调用方的方法出现异常，那么所有被调用方执行的成功的结果不会被回滚。
七、高并发中的事务问题
1.更新丢失
两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的：
第一类更新丢失(回滚覆盖)：撤消一个事务时，在该事务内的写操作要回滚，把其它已提交的事务写入的数据覆盖了;
第二类更新丢失(提交覆盖)：提交一个事务时，写操作依赖于事务内读到的数据，读发生在其他事务提交前，写发生在其他事务提交后，把其他已提交的事务写入的数据覆盖了，这是不可重复读的特例。
2.脏读
一个事务看到了另一个事务未提交的更新数据；当事务读取尚未提交的数据时，就会发生这种情况。
3.不可重复读
一个事务中两次读同一行数据，可是这两次读到的数据不一样。
4.幻读
一个事务中两次查询，但第二次查询比第一次查询多了或少了几行或几列数据。
八、事务的隔离级别
从理论上来说，事务应该彼此完全隔离，以避免并发事务所导致的问题(就如以上问题)。然而，那样会对性能产生极大的影响，因为事务必须按顺序运行；
在实际开发中，为了提升性能, 事务会以较低的隔离级别运行；
Spring支持的事务隔离级别：
待续...