《Spring实战》第六章读书笔记（事务管理）
事务四要素（ACID）：
1、原子性（Atomic）
事务是由一个或多个活动所组成的一个工作单元。原子性确保事务中的所有操作全部发生或全部不发生。如果所有的活动都成功了，事务也就成功了。如果任意一个活动失败了，整个事务也失败并回滚。
2、一致性（Consistent）
一旦事务完成（不管事务成功还是失败），系统必须确保它所建模的业务处于一致的状态。现实的数据不应该被损坏。
3、隔离性（Isolated）
事务允许多个用户对相同的数据进行操作，每个用户的操作不会与其他用户纠缠在一起。因此，事务应该被彼此隔离，避免发生同步读写相同数据的事情(隔离性往往设计到锁定数据库中的行或表)。
4、持久性（Durable）
一旦事务完成，事务的结果应该持久化，这样就能从任何的系统崩溃中恢复过来。这一般会设计将结果存储到数据库或其他形式的持久化存储中。
Spring并不直接管理事务，而是提供了多种事务管理器，它们将事务管理的职责委托给JTA或其他持久化机制所提供的平台相关的事务实现。下表列出了Spring的事务管理器。
| 事务管理器（org.framwork.*） | 使用场景 |
| jca.cci.connection.CciLocalTransactionManager | 使用Spring对JavaEE连接器架构和通用客户端接口提供支持 |
| jdbc.datasource.DataSourcetransactionManager | 用于Spring对JDBC抽象的支持。也可用于使用iBATIS进行持久化的场景 |
| jms.connection.JmsTransactionManager | 用于JMS1.1+ |
| jms.connection.JmsTransactionManager102 | 用于JMS1.0.2 |
| orm.hibernate3.HibernateTransactionManager | 用于Hibernate3进行持久化 |
| orm.jdo.JdoTransactionManager | 用于JDO进行持久化 |
| orm.jpa.JpaTransactionManager | 用于Java持久化API进行持久化 |
| transaction.jta.JtaTransactionManager | 需要分布式事务或者没有其他的事务管理器满足需求 |
| transaction.jta.OC4JJtaTransactionManager | 用于Oracle的OC4J JEE容器 |
| transaction.jta.WebLogicJtaTransactionManager | 需要使用分布式事务并且应用程序运行于weblogic中 |
| transaction.jta.WebSphereUowTransactionManager | 需要WebSphere中UOWManager所管理的事务 |
为了使用事务管理器，需要将其声明在应用程序上下文中。首先从DataSourceTransactionManager开始，它为简单的JDBC和iBATIS提供了事务支持。
JDBC事务：
为了使用DataSourceTransationManager，需要使用如下的XML将其装配到应用程序的上下文定义中：
要注意的是dataSource属性值配置乘客一个名为dataSource Bean的引用。而dataSource是定义在上下文文件中的javax.sql.DataSource Bean.
在幕后，DataSourceTransactionManager通过调用javax.sql.Connection来管理事务，而后者是通过DataSource获取到的。通过调用连接的commit()方法来提交事务。同样，事务失败时通过调用rollback()方法进行回滚。
Hibernate事务：
与JDBC事务配置相似，Hibernate事务也需要在Spring上下文定义中添加如下的bean声明：
sessionFactory属性需要装配一个Hibernate SessionFactory。
HibernateTransactionManager将事务管理的职责委托给org.hibernate.Transaction对象，而后者是从Hibernate Session中获取到的。当事务成功完成时，HibernateTransactionManager将会调用Transaction对象的commit()方法。类似地，如果事务失败，Transaction对象的rollback()方法将会被调用。
声明式事务：
Spring对声明式事务的支持是通过使用Spring AOP实现的。这是很自然的一件事，因为事务是在应用程序主要功能之上的系统级服务。可以将Spring事务想象成将方法"包装"上事务边界的切面。
Spring提供了3种方式来声明事务式边界。以前，Spring只能使用Spring AOP和TransactionProxyFactoryBean的代理Bean来实现声明式事务。但是自从Spring 2.0，声明事务的更好方式是使用Spring的tx命名空间和@Transactional注解。
定义事务属性：
在Spring中，声明式事务是通过事务属性(transaction attribute)来定义的。事务属性包含传播行为、隔离级别、只读、事务超时、回滚规则五个方面。
传播行为：
Spring定义了7种不同的传播行为：
| 传播行为 | 含义 |
| PROPAGATION_MANDATORY | 表示该方法必须在事务中运行。如果当前事务不存在，则会抛出一个异常。 |
| PROPAGATION_NESTED | 表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为与PROPAGATION_REQUIRED一样。 |
| PROPAGATION_NEVER | 表示当前方法不应该运行在事务上下文中。如果当前正有一个事务在运行，则会抛出异常。 |
| PROPAGATION_NOT_SUPPOTED | 表示该方法不应该运行在事务中。如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager。 |
| PROPAGATION_REQUIRED | 表示当前方法必须运行在事务中。如果当前事务存在，方法将会在该事务中运行。否则，会启动一个新的事务。 |
| PROPAGATION_REQUIRES_NEW | 表示当前方法必须运行在它自己的事务中。一个新的事务将被启动。如果存在当前事务，在该方法执行期间，当前事务会被挂起。如果使用JTATransactionManager，则需要访问TransactionManager。 |
| PROPAGATION_SUPPORTS | 表示当前方法不需要事务上下文，当时如果存在当前事务的话，那么该方法会在这个事务中运行。 |
隔离级别：
声明式事务的第二个维度就是隔离级别。隔离级别定义了一个事务可能受其他并发事务影响的程度。
在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务。并发，虽然是必需的，但可能会导致以下问题。
脏读（Dirty reads）：
脏读发生在一个事务读取了另一个事务改写但尚未提交的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。
不可重复读（Nonrepeatable read）：
不可重复读发生在一个事物执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间更新了数据。
幻读（Phantom read）:
幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的事务。
在最理想情况下，事物之间是完全隔离的，从而可以防止这些问题发生。但是完全的隔离会导致性能问题，因为它通常会涉及锁定数据库中的记录（有时候甚至是整张表）。侵占性的锁定会阻碍并发行，要求事务互相等待以完成各自的工作。
考虑到完全的隔离会导致性能问题，而且不是所有的应用程序都需要完全的隔离，所以有时应用程序需要在事务隔离上有一定的灵活性。因此，就会有多种隔离级别。如下图所示：
| 隔离级别 | 含义 |
| ISOLATION_DEFAULT | 使用后端数据库默认的隔离级别 |
| ISOLATION_READ_UNCOMMITTED | 允许读取未提交的数据变更。可能会导致脏读、幻读或不可重复读 |
| ISOLATION_READ_COMMITTED | 允许读取并发事务已经提交的数据。可以阻止脏读，但是幻读和不可重复读仍有可能发生 |
| ISOLATION_REPEATABLE_READ | 对同一字段的多次读取结果是一致的，除非数据是被本事务自己所修改。可以阻止脏读和不可重复读，但幻读仍有可能发生 |
| ISOLATION_SERIALIZABLE | 完全服从ACID的隔离级别，确保阻止脏读、不可重复读和幻读。这是最慢的事务隔离级别，因为它通常是通过完全锁定事务相关的数据库表来实现的。 |
只读：
声明式事务的第三个特性是它是否为只读事务。如果事务只对后端的数据库进行读操作，数据库可以利用事务的只读特性来进行一些特定的优化。通过将事务设置为只读，就可以给数据库一个机会，让它应用它认为合适的优化措施。
因为只读优化是在事务启动的时候由数据库实施的，只有对那些具备启动一个新事务的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIREDS_NEW以及PROPAGATION_NESTED）的方法来说，将事务声明为只读才有意义。
事务超时：
为了使应用程序很好的运行，事务不能运行太长的时间。因此，声明式事务下一个特性就是超时（timeout）。
假设事务的运行时间变得特别长。因为事务可能涉及对后端数据库的锁定，所以长时间的事务会不必要地占用数据库资源。可以声明一个事务，在特定的秒数后自动回滚，而不是等待其结束。
同样，因为超时时钟会在事务开始时启动，所以，只有对那些具备启动一个新事务的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIREDS_NEW以及PROPAGATION_NESTED）的方法来说，声明事务超时才有意义。
回滚规则：
回滚规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，事务只有在遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚。
但是可以通过声明使事务在遇到检查型异常也进行回滚，也可以声明遇到特定的异常不回滚，即使该异常是运行期异常。
定义注解驱动的事务：
除了
也可以通过transactionmanager属性（默认值为transactionmanager）来指定特定的事务管理器：
@Transactional注解的使用
@Transactional(propagation=Propagation.SUPPORTS,readOnly=true)
public class SpitterServiceImpl implements SpitterService{
@Transactional(propagation=Propagation.REQUIRED,readOnly=false)
public void addSpitter (Spitter spitter){ .....
}
}