关于事务隔离级别

隔离级别（isolation level）

l 隔离级别定义了事务与事务之间的隔离程度。

l 隔离级别与并发性是互为矛盾的：隔离程度越高，数据库的并发性越差；隔离程度越低，数据库的并发性越好。

l ANSI/ISO SQL92标准定义了一些数据库操作的隔离级别：

l 未提交读（read uncommitted）

l 提交读（read committed）

l 重复读（repeatable read）

l 序列化（serializable）

l 通过一些现象，可以反映出隔离级别的效果。这些现象有：

l 更新丢失（lost update）：当系统允许两个事务同时更新同一数据时，发生更新丢失。

l 脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。

l 非重复读（nonrepeatable read）：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。(A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. )

l 幻像（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。(A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition. )

l 下面是隔离级别及其对应的可能出现或不可能出现的现象

Dirty Read

NonRepeatable Read

Phantom Read

Read uncommitted

Possible

Possible

Possible

Read committed

Not possible

Possible

Possible

Repeatable read

Not possible

Not possible

Possible

Serializable

Not possible

Not possible

Not possible

 

定义事务代理
除了JdbcClinic实例以外，配置中也定义了一个事务代理。如果愿意这个代理所暴露的实际接口也可以显式定义。默认情况下，所有由目标对象实现的接口都暴露出来，在这个例子中就是应用的Clinic服务接口。

从客户端的观点来看，"clinic" bean只是这个应用的Clinic接口的实现。客户端不需要知道这会被一个事务代理所处理。这就是接口的能力：一个直接的目标对象的引用可以容易的被一个实现相同接口的代理所代替—在这儿就是一个隐式创建事务的代理。
代理的具体事务行为会由为根据特定的方法或方法命名模式而定义的事务属性来驱动，就像下面的例子所示：
清单3：

<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="store*">PROPAGATION_REQUIRED</prop>

Key属性决定代理将为方法提供什么样的事务行为。这个属性的最重要部分就是事务传播行为。下面是一些可选的属性值：
1、PROPAGATION_REQUIRED --支持当前的事务，如果不存在就创建一个新的。这是最常用的选择。
2、PROPAGATION_SUPPORTS --支持当前的事务，如果不存在就不使用事务。
3、PROPAGATION_MANDATORY --支持当前的事务，如果不存在就抛出异常。
4、PROPAGATION_REQUIRES_NEW --创建一个新的事务，并暂停当前的事务（如果存在）。
5、PROPAGATION_NOT_SUPPORTED --不使用事务，并暂停当前的事务（如果存在）。
6、PROPAGATION_NEVER --不使用事务，如果当前存在事务就抛出异常。
7、PROPAGATION_NESTED --如果当前存在事务就作为嵌入事务执行，否则与PROPAGATION_REQUIRED类似。

前6 个事务策略与EJB的CMT类似，而且使用相同的常量名，因此对EJB开发人员来说是很亲切的。第7个策略PROPAGATION_NESTED是 Spring提供的一个变体：他需要事务管理器(如DataSourceTransactionManager)提供类似JDBC3.0那样的保存点 API来嵌套事务行为或者通过
JTA支持嵌套事务。

事务属性中的readOnly标识指示相应的事务应该作为一个只读事务来优化。这是一个优化提示：一些事务策略在这种情况下可以得到很好的性能优化，如使用ORM工具如Hibernate或TopLink时避免脏数据检查（“flush”尝试）。

在事务属性中还有一个“timeout”选项来定义事务的超时秒数。在JTA中，这个属性会简单地传递给J2EE服务器的事务协调器并被正确地解释。

使用事务代理
在运行时，客户端会取得一个“clinic”引用并转换为Clinic接口，然后调用如loadPet或storePet方法。这就隐式地使用了 Spring的事务代理，通过“事务解释器”在目标对象中注册；这样一个新的事务就创建了，然后具体的工作就会代理给JdbcClinic的目标方法。
图1示例了一个使用“建议链”并到达最后目标的AOP代理的潜在概念。在这个示例中，唯一的建议是一个事务解释器用来包装目标方法的事务行为。这是一种用来在声明性事务功能下使用的基于代理的AOP。



Figure 1. An AOP proxy with an advisor chain and a target at the end

例如，一个PetClinic应用的WEB层组件可以执行ServletContext定位来获取Spring WebApplicationContext的引用并且获取受管理的“clinic”BEAN：
清单4：

WebApplicationContext ctx = 
   WebApplicationContexUtils.getWebApplicationContext(servletContext);
Clinic clinic = (Clinic) ctx.getBean("clinic);

Pet pet = new Pet();
pet.setName("my new cat");

clinic.storePet(pet);

在调用storePet()之前，Spring的事务代理隐式地创建一个事务。当storePet()调用返回时，事务将提交或回滚。缺省情况下任何 RuntimeException或Error将导致回滚。实际的提交或回滚可以是可以定义的：Spring的事务属性支持“回滚规则”的概念。

例如，我们可以可以引入一个强制的PetClinicException并且告诉事务代理在抛出异常时回滚：
清单5：

<prop key="load*">PROPAGATION_REQUIRED,readOnly,-PetClinicException</prop>
<prop key="store*">PROPAGATION_REQUIRED,-PetClinicException</prop>

这儿也有一个类似的“提交规则”语法，指示特定的异常将触发一次提交。
注意上面示例的显式定位引用的方法只是一种访问受Spring管理BEAN的方法的变化，可以用在任何WEB资源如servlet或filter。在构建基于Spring自身的MVC框架时，BEAN可以直接被注射到WEB控制器中。当然也支持在如Struts, WebWork, JSF, and Tapestry框架中访问Spring管理BEAN。详情可以参考Spring的文档。

PlatformTransactionManager策略

Spring 事务支持的核心接口是org.springframework.transaction.PlatformTransactionManager。所有 Spring的事务分离功能都会委托给PlatformTransactionManager（传给相应的TransactionDefinition实例）来做实际的事务执行。虽然PlatformTransactionManager接口可以直接调用，但通常应用只需要配置一个具体的事务管理器并且通过声明性事务来分离事务。

Spring提供几种不同的PlatformTransactionManager实现，分为如下两个类别：
1、本地事务策略—支持单一资源的事务（通常是单个数据库），其包括 org.springframework.jdbc.datasource.DataSourceTransactionManager和 org.springframework.orm.hibernate.HibernateTransactionManager。
2、全局事务管理—支持可能跨越多个资源的全局事务。其相应的类为org.springframework.transaction.jta.JtaTransactionManager，将事务委托给遵循JTA规范的事务协调器（通常为J2EE服务器，但不是强制的）。

PlatformTransactionManager 抽象的主要价值在于应用不再被绑定在特定的事务管理环境。相反，事务策略可以很容易地切换—通过选择不同的 PlatformTransactionManager实现类。这就使得应用代码与声明事务分离保持一致，而不需要考虑应用组件所使用的环境了。

例如，应用的初始版本可能布署在Tomcat上，与单个Oracle数据库交互。这可以方便地利用Spring的事务分离特性，只要选择基于JDBC的 DataSourceTransactionManager作为使用的事务策略。Spring会分离事务，而JDBC驱动会执行相应的原始JDBC事务。

相同应用的另一个版本可能会布署在WebLogic服务器上，使用两个Oracle数据库。应用代码和事务分离不需要改变。唯一不同的是选择作为 JtaTransactionManager事务策略，让Spring来分离事务而WebLogic服务器的事务协调器来执行事务。

JTA UserTransaction与JTA TransactionManager比较
让我们来看一下Spring对JTA支持的细节。虽然并非经常需要考虑这个细节但了解相关的细节还有必要的。对简单的用例如前面章节的示例，标准的JtaTransactionManager定义已经足够了，
缺省的Spring JtaTransactionManager设置会从标准JNDI位置（J2EE规范所定义的java:comp/UserTransaction）获取 JTA的javax.transaction.UserTransaction对象。这对大部分标准J2EE环境来说已经足够了。

然而，缺省的JtaTransactionManager不能执行事务暂停（也就是说不支持PROPAGATION_REQUIRES_NEW和 PROPAGATION_NOT_SUPPORTED）。原因就在于标准的JTA UserTransaction接口不支持事务的暂停和恢复，而只支持开始和完成新的事务。

为了实现事务的暂停，需要一个 javax.transaction.TransactionManager实例，他提供了JTA定义的标准的暂停和恢复方法。不幸的是，J2EE没有为 JTA TransactionManager定义标准的JNDI位置！因此，我们需要使用厂商自己的定位机制。
清单6：

<bean id="transactionManager" 
   class="org.springframework.transaction.jta.JtaTransactionManager">
     <property name="transactionManagerName">
        <value>vendorSpecificJndiLocation</value>
     </property>
</bean>

J2EE 本质上没有考虑将JTA TransactionManager接口作为公共API的一部分。JTA规范自身定义了将TransactionManager接口作为容器集成的想法。虽然这是可以理解的，但是JTA TransactionManager的标准JNDI位置还是可以增加一定的价值，特别是对轻量级容器如Spring,这样任何J2EE服务器就可以用统一的方式来定位JTA TransactionManager了。

不仅Spring的JtaTransactionManager可以从访问中获益，O/R映射工具如Hibernate, Apache OJB, and Kodo JDO也能得到好处，因为他们需要在JTA环境中执行缓存同步的能力（释放缓存意味着JTA事务的完成）。这种注册事务同步的能力只有JTA TransactionManager接口才能提供，而UserTransaction是处理不了的。因此，这些工具都需要实现自己的 TransactionManager定位器。

为JTA TransactionManager定义标准的JNDI位置是许多底层软件供应商最期望J2EE实现的功能。如果J2EE5.0的规范制定团队能够认识到这个特性的重要性就太好了。幸运地是，高级J2EE服务器如WebLogic Server已经考虑将JTA TransactionManager作为公共的API包含在扩展功能中。

在WebLogic JTA中实现Spring的事务分离
在WebLogic Server中，JTA TransactionManager官方的JNDI位置定义为javax.transaction.TransactionManager。这个值可以在Spring的JtaTransactionManager中作为“transactionManagerName”使用。原则上这样就可以在 WebLogic's JTA系统中实现事务暂停了，也就是说支持PROPAGATION_REQUIRES_NEW和PROPAGATION_NOT_SUPPORTED行为。

除了标准的JtaTransactionManager和其支持的通用配置选项外，Spring还提供了一个专用的WebLogicJtaTransactionManager适配器来直接利用WebLogic的JTA扩展。

在享受自动探测WebLogic的JTA TransactionManager的便利之外，他提供超越标准JTA的三个重要特性：
1、事务命名—暴露出Spring的事务名给WebLogic Server，使得Spring事务在WebLogic的事务监听器可见。缺省的，Spring会使用声明性事务的完整方法名。
2、每事务隔离级别—将Spring事务属性中定义的隔离级别应用到WebLogic JTA事务中。这使得每个事务都可以定义数据库的隔离级别，而这是标准JTA所不支持的。
3、强制事务恢复—即使在暂停的事务被标识为回滚时也可以恢复。这需要使用WebLogic的扩展TransactionManager接口来调用forceResume()方法。


Figure 2. WebLogic Server's transaction monitor (click the image for a full-size screen shot)

Spring的WebLogicJtaTransactionManager有效地为基于Spring的应用提供了WebLogic Server事务管理的全部功能。这使得Spring事务分离成为一种能与EJB CMT竟争的产品，而且提供了相同级别的事务支持。

Spring and EJB CMT

如上所示，Spring的POJO声明性事务分离可以作为一种除传统EJB CMT这外的选择。但是Spring与EJB并不是完成互斥的，Spring的应用上下文也可以作为EJB façade的后台来管理数据访问（DAO）和其他细纹理的业务对象。

在EJB情景中，事务是由EJB CMT来驱动的。对Spring来说，数据访问支持特性会自动检测到这样的环境并且采用相应的事务。例如，Spring对Hibernate的支持能够提供隐式的资源管理，即使是EJB驱动的事务，甚至可以在不需要修改任何DAO代码的情况下提供相同的语义。
Spring有效的解耦了DAO实现与实际的运行环境。DAO可以参与Spring的事务就像参与EJB CMT事务一样。这不仅简化在其他环境中的重用，而且更方便在J2EE容器外进行测试。

结论
Spring框架为J2EE和非J2EE环境提供了全量的事务分离的特性，特别表现在POJO的声明性事务上。他用一种灵活而非侵入式的方式为非EJB环境中的事务分离提供了便利。与EJB不同，这样的事务性POJO应用对象可以很容易的被测试和在J2EE容器外补重用。

Spring 提供了各种事务策略，如JtaTransactionManager是用来代理J2EE服务器的事务协调器，而JDBC DataSourceTransactionManager是用来为简单的JDBC DataSource（就是单一目标数据库）执行事务。Spring可以很容易为不同的环境通过后台配置的简单修改来调整事务策略。

超越标准的JTA支持，Spring为WebLogic Server的JTA扩展提供了完善的集成，可以支持高级特性如事务监视和每事务隔离级别。通过对WebLogic Server的特殊支持，基于Spring的应用可以完全利用WebLogic Server的事务管理功能。

Spring事务分离是继 EJB CMT之外的另一种可选方式，特别是对那些基于POJO的轻量级架构。在那只是因为选择LSSB（本地无状态会话BEAN）来应用声明性事务的情况下，基于Spring的POJO服务模型是一种可行的选择，他提供了非常高层的灵活性、可测试性和重用性。

资源
•JTA - The JTA specification JTA规范
•WebLogic JTA - Documentation of WebLogic's JTA extensions WebLogic  JTA扩展文档

关于作者
Juergen Hoeller是Spring框架的创始人之一