Spring为事务管理提供一流的支持。它同时支持编程式和声明式事务。为实现健壮的企业级应用,事务能担当重要的作用。无论是使用编程式事务还是声明式事务,在开发Spring应用时,开发者都不需要对具体的事务管理实现进行交互。
事务管理抽象是Spring提供的最重要的一种抽象。秉承Spring的设计原则,对于事务管理而言,[color=red]Spring的事务管理具有如下几方面的优势[/color]:
1)对于采用手工控制事务,即程序控制事务的编程方式,[color=blue]Spring提供的事物抽象易于使用。[/color]
2)无论底层的事务API是什么,[color=blue]Spring都能够提供一致的编程模型[/color]。比如,对于提供分布式事务支持的JTA、JDBC、Hibernate等而言,基于Spring的应用代码等都是一致,而没有专属于某事物API的实现。其中,特定的事务API都可以通过Spring配置文件屏蔽掉。
3)[color=blue]Spring支持声明式事务管理[/color]。这主要依赖于Spring AOP提供的功能。因此,Spring AOP在Spring事务抽象服务中起了重要的作用。
4)[color=blue]能够同Spring的DAO抽象进行集成[/color]。
5)[color=blue]在不同事务服务间切换,只会涉及到Spring配置文件的修改[/color],而不会涉及到代码的修改。
[b]1.事务管理背景[/b]
对于事务管理而言,存在两种事务类型:[color=red]局部(本地,local)事务和全局(global)事务。[/color]
对于本地事务而言,只涉及到单个事务性(可恢复)资源,通常都是JDBC级的事务。对于全局事务而言,通常都涉及到两个以上事务性资源,比如两个不同的数据库、数据库和JMS服务器。如果应用只涉及到单个事务性资源,则无需借助于J2EE应用服务器提供的JTA能力,而只需借助于本地事务即可解决事务管理服务方面的问题。如果应用涉及到两个以上的事务性资源,则需要J2EE应用服务器的JTA能力。
从性能上考虑,全局事务是“致命”的。[color=blue]能够不用全局事务,则尽量不用[/color]。但对于企业级应用而言,经常不可避免地碰到这种场景。为在应用代码中使用JTA功能,必须通过JNDI获得JTA的引用,继而应用代码需要处理大量的受查异常。对于Web容器而言,通常都不提供JTA的实现,即不支持全局事务,除非外挂JTA事务管理器实现,比如Open Source JOTM。对于J2EE应用服务器而言,比如JBoss、WebLogic、WebSphere、Oracle Application Server、Sun Java System Application Server等,都提供了对JTA的支持。当然不同的应用服务器对JTA的支持程度也不尽相同。
从易用性角度考虑,本地事务更容易使用。但是,它不能保证同事处理多个事务性资源的正确性。通常,事务都具有ACID的特性。
1)A原子性。事务必须成功提交,或者回滚;
2)C一致性;
3)I隔离性;
4)D持久性
ACID,是所有事务管理过程中必须保证的特性。
EJB提供的容器事务管理(Container Managed Transaction,CMT),可以通过在ejb-jar.xml文件中进行事务声明,而不需要应用代码的介入。但是CMT要求EJB容器支持,且只对EJB容器有效。在实际应用中,如何对POJO生效类似的CMT功能呢?
Spring可以解决这个问题。Spring承诺:在任何场景中,使用一致的编程模型,而不会影响对事务的使用;或者说,在使用事务的地方,不会影响编程的模式。尽管Spring同时提供了对声明式和编程式的事务管理支持,不过推荐使用声明式的事务管理。在大部分场合,编程式的事务管理更具灵活性。不过在引入Spring AOP后,情况未必是这样。
[b]2.Spring对事务管理提供的支持[/b]
Spring同时支持如下两种事务编程模型:声明式和编程式
对于声明式事务而言,Spring支持各种事务管理器,而不像EJB。EJB仅仅支持JTA(Java Transaction API)。注意,JTA是EJB(对于容器管理事务而言)提供事务支持的唯一事务实现。借助于Spring AOP模块,能够实现Spring提供的声明式事务管理。在J2EE平台中,事务常常作为企业级服务看待,因此它是系统级的。企业应用在完成业务逻辑操作时,需要借助于事务服务,因此将Spring提供的事务抽象作为AOP中的Aspect看待时很合理的事情,即在Spring中提供了事务方面(Aspect),这同JBoss AOP提供的事务方面类似。在Spring事务抽象服务中,提供了TransactionProxyFactoryBean类,供实现声明式事务使用。
对编程式事务而言,Spring也支持各种事务管理器。而且,它比声明式事务更灵活。如果在Spring应用中,仅仅使用到单个的事务性资源,则开发者可以不使用JTA实现。比如,可以直接使用JDBC(DataSourceTransactionManager)、Hibernate、JDO、OJB、JMS、JTA。为支持全局事务,即存在两个以上的事务性资源,则必须借助于第三方JTA实现,比如Open Source JOTM。
需要注意的是,Spring提供的事务管理器仅仅是对现有的事务实现API(比如,Hibernate、JDBC、JTA)进行封装,其本身并没有提供具体的事务管理实现。
在Spring提供的所有事务管理器中,PlatformTransactionManager是最基本的接口。
Spring提供了若干实现,供Spring Ioc实现控制反转使用。对于Hibernate而言,需要借助于HibernateTransactionManager事务管理器。开发者需为它提供seeionFactory取值。
实际上,HibernateTransactionManager将会事务处理的具体工作委派给Hibernate中的net.sf.hibernate.Transaction对象。其实,在Spring提供的所有事务管理器中,都是对底层事务对象的封装。它自身并没有实现底层事务的管理。符合Spring的设计原则:“不重复开发轮子”。因此,对HibernateTransactionManager的commit和rollback操作将委派给Transaction对象。
其中,HibernateTransactionManager就是实现了PlatformTransactionManager接口,而且是通过Spring Ioc容器加载的。
Spring提供的实现了PlatformTransactionManager接口的主要事务管理器有:
JDBC事务:借助于DataSourceTransactionManager实现
JTA事务:借助于JtaTransactionManager、WebLogicJtaTransactionManager实现。
Hibernate事务:借助于HibernateTransactionManager实现;
JDO事务:借助于JdoTransactionManager实现;
……
对于JDBC事务而言,需要配置DataSourceTransactionManager。配置示例如下。
开发者需要为它准备dataSource取值。至于dataSource的具体来源(是基于JNDI,还是其他机制),DataSourceTransactionManager可以不用关注。这或许是Ioc的好处,而且还可以在产品部署场合动态切换。DataSourceTransactionManager将事务的commit和rollback操作委派给java.sql.Connection。
2.1)[b]声明式事务[/b]
在J2EE中,EJB因为可以使用声明式事务而著称。现在Spring也能支持声明式事务,不仅如此,借助于Acegi,Spring还能实现声明式安全性。注:这里的声明式事务针对的是POJO对象。
借助于Spring AOP,Spring提供了TransactionProxyFactoryBean。它是为简化声明式事务处理而引入的代理工厂JavaBean。当然,也可以使用ProxyFactoryBean和TransactionInterceptor的组合。在TransactionProxyFactoryBean内部使用了事务拦截器,即TransactionInterceptor。
(2.1.1)[b]TransactionDefinition[/b]
Java对象本身由属性和方法构成。对于事务而言,它也存在若干事务属性。通常,事务会涉及到事务移植、隔离级别、是否只读、事务有效实现等。这些属性都是通过如下接口定义的:TransactionDefinition。它位于org.springframework.transaction包中。
在CMT中,开发者可以对事务移植性(propagation)进行配置。在RDBMS中,可以配置数据库的隔离度(isolation)。
对于事务移植而言,TransactionDefinition定义了7中移植策略。
a)int PROPAGATION_REQUIRED = 0。当前方法必须运行于事务中,这同EJB中声明式事务语义相同。即,如果调用其客户处于事务中,则该方法直接使用该事务;否则,启动新事务。
b)int PROPAGATION_SUPPORTS = 1。当前方法可以在事务中,也可以不在事务中。调用其客户在事务中,则当前方法处于事务中。否则,不处于事务中。
c)int PROPAGATION_MANDATORY = 2。当前方法必须运行于事务中。若调用其客户不在事务中,则抛出异常。
d)int PROPAGATION_REQUIRES_NEW = 3。必须运行于新事务中。无论客户如何,都将启动新事务。
e)int PROPAGATION_NOT_SUPPORTED = 4。当前方法不能运行于事务中。如果调用其客户处于事务中,则在执行到它时,客户所处的事务必须挂起。如果调用其客户不处于事务中,则一切照旧。
f)int PROPAGATION_NEVER = 5。调用当前方法的客户不能处于事务中,否则抛出异常。
g)int PROPAGATION_NESTED = 6。它表明当前方法支持嵌入式事务,即允许事务嵌套。标准的J2EE平台不要求支持嵌套事务。这是对EJB声明式事务的扩展。通常,低端的JTA实现都不支持这种事务移植性。
对于隔离级别,Spring TransactionDefinition定义了5中事务策略。
a)int ISOLATION_DEFAULT = -1。它表明直接使用底层持久化源使用的隔离级别定义。
b)int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED。同Connection定义的TRANSACTION_READ_UNCOMMITTED定义。
c)int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED。同Connection定义的TRANSACTION_READ_COMMITTED定义。
d)int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ。
e)int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE。
对于只读属性而言,Spring TransactionDefinition仅对当前方法新创建的事务有效。通过“readonly”标识。在一些场合设置readonly很有效,比如在使用Hibernate时,如果只是从RDBMS读取数据,则能提高事务效率(避免不必要的flush操作)。
对于事务有效时限而言,Spring TransactionDefinition仅对当前方法新创建的事务有效。通过设置以“timeout_”开头的字符串能够生效有效时限属性。比如“timeout_60”表明事务的有效时限是60秒。默认时,它会使用底层事务系统的超时设置。即:int TIMEOUT_DEFAULT = -1。
上述就是Spring TransactionDefinition的定义,这也是Spring所支持的事务属性设置。
如下是一段applicationContext.xml中的实例:
注意属性transactionAttributes中的配置,其中对事务的移植性进行了约束。其中,通过transactionManager属性指定事务管理器;通过target属性指定TransactionProxyFactoryBean代理的目标业务对象;通过transactionAttributes属性指定事务策略。在Spring框架中,特意提供了org.springframework.transaction.interceptor.TransactionAttributeEditor,供实现事务策略的手工编辑使用。借助于该属性编辑器,使自定义事务策略的过程更友好。上述配置内容的具体解释如下:
a)对于“get*”:这表明以get开头的业务方法(前提是,位于example11ServiceTarget中定义的JavaBean)必须处于事务中,这是通过PROPAGATION_REQUIRED限定的。如果调用客户不在事务上下文中,或者没有提供事务支持,则会创建新的事务。其中,readonly表明这是只读事务,这对于Hibernate而言特别有意义。
b)对于“set*”:这表明以set开头的业务方法(前提是,位于example11ServiceTarget中定义的JavaBean)必须处于事务中,这是通过PROPAGATION_REQUIRED限定的。如果调用客户不在事务上下文中,或者没有提供事务支持,则会创建新的事务。
c)其中设置的事务属性顺序并不重要,因为TransactionAttributeEditor会自动处理它们。比如PROPAGATION_REQUIRED,readOnly和readOnly,PROPAGATION_REQUIRED含义相同。
对于Spring提供的声明式事务支持,开发者能获得如下几方面的益处:
1)借助于Spring AOP提供了类似EJB CMT(容器事务管理)的功能。而且,能够对POJO进行事务性声明。
2)Spring提供的声明式事务能够适用于任何操作环境。比如,JDBC,Hibernate,JDO等,如果有新的事务性资源的加入,对于Spring应用而言,只需要修改下配置文件即可。
3)Spring还提供了声明式的回滚规则,比如,可以声明:如果某异常一旦抛出,事务必须回滚。比如,在事务属性中设置“-UserException”,则表明在事务处理过程中一旦出现UserException,则回滚当前事务。如设置“+UserException”,则表明在事务处理过程中一旦出现UserException,则提交当前事务。加号表示提交,减号表示回滚。这是很诱人的技术。
另外,Spring还提供了通过元数据(比如借助于Jakarta Commons Attributes)、指定方法名(org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource)、自动代理等方式定义事务策略。
2.2)[b]编程式事务[/b]
编程式事务比声明式事务更具灵活性。由于Spring AOP实现的拦截器只能拦截方法级的调用,因此如果需要事务支持,则整个方法处于事务中。如果存在遗留代码需要借助于Spring管理,则此时Spring可能不能够胜任。但无论如何,如果我们架构并设计新的企业应用系统,可以考虑到Spring的这种特性,更何况这是开发者大部分场合需要考虑的情况。
Spring为编程式事务提供了两种策略:
a)直接使用TransactionTemplate:这同JndiTemplate、JdbcTemplate、HibernateTemplate类似。由于TransactionTemplate是线程安全的,可以放心使用。
b)直接使用PlatformTransactionManager实现。开发者可以推导,TransactionTemplate一定需要PlatformTransactionManager实现,否则无法完成事务管理操作。因此,直接借助于PlatformTransactionManager实现一定能完成事务管理操作。当然,直接借助于PlatformTransactionManager实现事务管理,会比使用事务模版完成更多的设置和准备工作。
Spring team推荐:通常都最好使用TransactionTemplate
2.2.1)使用TransactionTemplate
Spring框架提供的、类似TransactionTemplate的模版有许多。它们是采用回调机制实现方法调用的。在方法调用期间,TransactionTemplate会将要求的资源准备好(调用开始)和释放掉(调用结束),这是模版的威力。在Spring中,所有模版都是线程安全的。
在使用TransactionTemplate之前,需要在Spring配置文件中进行配置。示例如下:
transactionManager是TransactionTemplate的属性,因此事务模版需借助Spring提供的事务管理器实现处理事务管理。事务模版可以使用Hibernate、JTA、JDBC、JDO等事务管理器。
[b]也可以基于TransactionTemplate的构建器来注入对事务管理器的依赖。[/b]接下来,开发者便能在java代码中直接使用TransactionTemplate了。依据Spring模版设计原则,Spring为TransactionTemplate准备了两个回调接口:TransactionCallback和TransactionCallbackWithoutResult。
a)org.springframework.transaction.support.TransactionCallback:用于事务的回调接口。通常,它都是伴随着TransactionTemplate并以匿名方式使用的。它仅含有单个方法,即doInTransaction。如果事务操作存在返回值,则使用TransactionCallback。如果不存在返回值,则使用TransactionCallbackWithoutResult接口。
b)org.springframework.transaction.support.TransactionCallbackWithoutResult:继承于TransactionCallback。TransactionCallbackWithoutResult供事务操作不存在返回值时使用。
对于存在返回值的业务方法而言,示例如下:
其中,开发者需要实现Object doInTransaction(TransactionStatus status)方法。现在updateOperation1()、updateOperation2()、updateOperation3()都处于同一事务中,因此他们构成了ACID的特性。若出现异常,则事务回滚(借助于status的setRollbackOnly实现)。
对于不存在返回值的业务方法而言。示例如下:
如果应用需要回滚,则需要调用TransactionStatus对象的setRollbackOnly方法。对于有EJB组件开发经验的人而言,能够看出这与CMT极其相似。
2.2.2)使用PlatformTransactionManager实现
借助于Spring IoC容器提供的控制反转,能够直接在应用代码中直接获得对<bean>元素中定义的PlatformTransactionManager实现。示例如下:
注,上面的实现方式也是在模拟TransactionTemplate的行为,因此,[color=red]在编程式事务中,最好直接使用TransactionTemplate。[/color]
事务管理抽象是Spring提供的最重要的一种抽象。秉承Spring的设计原则,对于事务管理而言,[color=red]Spring的事务管理具有如下几方面的优势[/color]:
1)对于采用手工控制事务,即程序控制事务的编程方式,[color=blue]Spring提供的事物抽象易于使用。[/color]
2)无论底层的事务API是什么,[color=blue]Spring都能够提供一致的编程模型[/color]。比如,对于提供分布式事务支持的JTA、JDBC、Hibernate等而言,基于Spring的应用代码等都是一致,而没有专属于某事物API的实现。其中,特定的事务API都可以通过Spring配置文件屏蔽掉。
3)[color=blue]Spring支持声明式事务管理[/color]。这主要依赖于Spring AOP提供的功能。因此,Spring AOP在Spring事务抽象服务中起了重要的作用。
4)[color=blue]能够同Spring的DAO抽象进行集成[/color]。
5)[color=blue]在不同事务服务间切换,只会涉及到Spring配置文件的修改[/color],而不会涉及到代码的修改。
[b]1.事务管理背景[/b]
对于事务管理而言,存在两种事务类型:[color=red]局部(本地,local)事务和全局(global)事务。[/color]
对于本地事务而言,只涉及到单个事务性(可恢复)资源,通常都是JDBC级的事务。对于全局事务而言,通常都涉及到两个以上事务性资源,比如两个不同的数据库、数据库和JMS服务器。如果应用只涉及到单个事务性资源,则无需借助于J2EE应用服务器提供的JTA能力,而只需借助于本地事务即可解决事务管理服务方面的问题。如果应用涉及到两个以上的事务性资源,则需要J2EE应用服务器的JTA能力。
从性能上考虑,全局事务是“致命”的。[color=blue]能够不用全局事务,则尽量不用[/color]。但对于企业级应用而言,经常不可避免地碰到这种场景。为在应用代码中使用JTA功能,必须通过JNDI获得JTA的引用,继而应用代码需要处理大量的受查异常。对于Web容器而言,通常都不提供JTA的实现,即不支持全局事务,除非外挂JTA事务管理器实现,比如Open Source JOTM。对于J2EE应用服务器而言,比如JBoss、WebLogic、WebSphere、Oracle Application Server、Sun Java System Application Server等,都提供了对JTA的支持。当然不同的应用服务器对JTA的支持程度也不尽相同。
从易用性角度考虑,本地事务更容易使用。但是,它不能保证同事处理多个事务性资源的正确性。通常,事务都具有ACID的特性。
1)A原子性。事务必须成功提交,或者回滚;
2)C一致性;
3)I隔离性;
4)D持久性
ACID,是所有事务管理过程中必须保证的特性。
EJB提供的容器事务管理(Container Managed Transaction,CMT),可以通过在ejb-jar.xml文件中进行事务声明,而不需要应用代码的介入。但是CMT要求EJB容器支持,且只对EJB容器有效。在实际应用中,如何对POJO生效类似的CMT功能呢?
Spring可以解决这个问题。Spring承诺:在任何场景中,使用一致的编程模型,而不会影响对事务的使用;或者说,在使用事务的地方,不会影响编程的模式。尽管Spring同时提供了对声明式和编程式的事务管理支持,不过推荐使用声明式的事务管理。在大部分场合,编程式的事务管理更具灵活性。不过在引入Spring AOP后,情况未必是这样。
[b]2.Spring对事务管理提供的支持[/b]
Spring同时支持如下两种事务编程模型:声明式和编程式
对于声明式事务而言,Spring支持各种事务管理器,而不像EJB。EJB仅仅支持JTA(Java Transaction API)。注意,JTA是EJB(对于容器管理事务而言)提供事务支持的唯一事务实现。借助于Spring AOP模块,能够实现Spring提供的声明式事务管理。在J2EE平台中,事务常常作为企业级服务看待,因此它是系统级的。企业应用在完成业务逻辑操作时,需要借助于事务服务,因此将Spring提供的事务抽象作为AOP中的Aspect看待时很合理的事情,即在Spring中提供了事务方面(Aspect),这同JBoss AOP提供的事务方面类似。在Spring事务抽象服务中,提供了TransactionProxyFactoryBean类,供实现声明式事务使用。
对编程式事务而言,Spring也支持各种事务管理器。而且,它比声明式事务更灵活。如果在Spring应用中,仅仅使用到单个的事务性资源,则开发者可以不使用JTA实现。比如,可以直接使用JDBC(DataSourceTransactionManager)、Hibernate、JDO、OJB、JMS、JTA。为支持全局事务,即存在两个以上的事务性资源,则必须借助于第三方JTA实现,比如Open Source JOTM。
需要注意的是,Spring提供的事务管理器仅仅是对现有的事务实现API(比如,Hibernate、JDBC、JTA)进行封装,其本身并没有提供具体的事务管理实现。
在Spring提供的所有事务管理器中,PlatformTransactionManager是最基本的接口。
Spring提供了若干实现,供Spring Ioc实现控制反转使用。对于Hibernate而言,需要借助于HibernateTransactionManager事务管理器。开发者需为它提供seeionFactory取值。
实际上,HibernateTransactionManager将会事务处理的具体工作委派给Hibernate中的net.sf.hibernate.Transaction对象。其实,在Spring提供的所有事务管理器中,都是对底层事务对象的封装。它自身并没有实现底层事务的管理。符合Spring的设计原则:“不重复开发轮子”。因此,对HibernateTransactionManager的commit和rollback操作将委派给Transaction对象。
<bean id="transactionManager"
class="org.springframework.orm.hibernate.HibernateTransactionManager">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
</bean>
其中,HibernateTransactionManager就是实现了PlatformTransactionManager接口,而且是通过Spring Ioc容器加载的。
Spring提供的实现了PlatformTransactionManager接口的主要事务管理器有:
JDBC事务:借助于DataSourceTransactionManager实现
JTA事务:借助于JtaTransactionManager、WebLogicJtaTransactionManager实现。
Hibernate事务:借助于HibernateTransactionManager实现;
JDO事务:借助于JdoTransactionManager实现;
……
对于JDBC事务而言,需要配置DataSourceTransactionManager。配置示例如下。
<bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource">
<ref local="dataSource"/>
</property>
</bean>
<bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>java:/MySqlDS</value>
</property>
</bean>
开发者需要为它准备dataSource取值。至于dataSource的具体来源(是基于JNDI,还是其他机制),DataSourceTransactionManager可以不用关注。这或许是Ioc的好处,而且还可以在产品部署场合动态切换。DataSourceTransactionManager将事务的commit和rollback操作委派给java.sql.Connection。
2.1)[b]声明式事务[/b]
在J2EE中,EJB因为可以使用声明式事务而著称。现在Spring也能支持声明式事务,不仅如此,借助于Acegi,Spring还能实现声明式安全性。注:这里的声明式事务针对的是POJO对象。
借助于Spring AOP,Spring提供了TransactionProxyFactoryBean。它是为简化声明式事务处理而引入的代理工厂JavaBean。当然,也可以使用ProxyFactoryBean和TransactionInterceptor的组合。在TransactionProxyFactoryBean内部使用了事务拦截器,即TransactionInterceptor。
(2.1.1)[b]TransactionDefinition[/b]
Java对象本身由属性和方法构成。对于事务而言,它也存在若干事务属性。通常,事务会涉及到事务移植、隔离级别、是否只读、事务有效实现等。这些属性都是通过如下接口定义的:TransactionDefinition。它位于org.springframework.transaction包中。
在CMT中,开发者可以对事务移植性(propagation)进行配置。在RDBMS中,可以配置数据库的隔离度(isolation)。
对于事务移植而言,TransactionDefinition定义了7中移植策略。
a)int PROPAGATION_REQUIRED = 0。当前方法必须运行于事务中,这同EJB中声明式事务语义相同。即,如果调用其客户处于事务中,则该方法直接使用该事务;否则,启动新事务。
b)int PROPAGATION_SUPPORTS = 1。当前方法可以在事务中,也可以不在事务中。调用其客户在事务中,则当前方法处于事务中。否则,不处于事务中。
c)int PROPAGATION_MANDATORY = 2。当前方法必须运行于事务中。若调用其客户不在事务中,则抛出异常。
d)int PROPAGATION_REQUIRES_NEW = 3。必须运行于新事务中。无论客户如何,都将启动新事务。
e)int PROPAGATION_NOT_SUPPORTED = 4。当前方法不能运行于事务中。如果调用其客户处于事务中,则在执行到它时,客户所处的事务必须挂起。如果调用其客户不处于事务中,则一切照旧。
f)int PROPAGATION_NEVER = 5。调用当前方法的客户不能处于事务中,否则抛出异常。
g)int PROPAGATION_NESTED = 6。它表明当前方法支持嵌入式事务,即允许事务嵌套。标准的J2EE平台不要求支持嵌套事务。这是对EJB声明式事务的扩展。通常,低端的JTA实现都不支持这种事务移植性。
对于隔离级别,Spring TransactionDefinition定义了5中事务策略。
a)int ISOLATION_DEFAULT = -1。它表明直接使用底层持久化源使用的隔离级别定义。
b)int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED。同Connection定义的TRANSACTION_READ_UNCOMMITTED定义。
c)int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED。同Connection定义的TRANSACTION_READ_COMMITTED定义。
d)int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ。
e)int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE。
对于只读属性而言,Spring TransactionDefinition仅对当前方法新创建的事务有效。通过“readonly”标识。在一些场合设置readonly很有效,比如在使用Hibernate时,如果只是从RDBMS读取数据,则能提高事务效率(避免不必要的flush操作)。
对于事务有效时限而言,Spring TransactionDefinition仅对当前方法新创建的事务有效。通过设置以“timeout_”开头的字符串能够生效有效时限属性。比如“timeout_60”表明事务的有效时限是60秒。默认时,它会使用底层事务系统的超时设置。即:int TIMEOUT_DEFAULT = -1。
上述就是Spring TransactionDefinition的定义,这也是Spring所支持的事务属性设置。
如下是一段applicationContext.xml中的实例:
<bean id="example11Service"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref local="transactionManager"/>
</property>
<property name="target">
<ref local="example11ServiceTarget"/>
</property>
<property name="transactionAttributes">
<props>
<prop key="get*">
PROPAGATION_REQUIRED,readOnly
</prop>
<prop key="set*">
PROPAGATION_REQUIRED
</prop>
</props>
</property>
</bean>
注意属性transactionAttributes中的配置,其中对事务的移植性进行了约束。其中,通过transactionManager属性指定事务管理器;通过target属性指定TransactionProxyFactoryBean代理的目标业务对象;通过transactionAttributes属性指定事务策略。在Spring框架中,特意提供了org.springframework.transaction.interceptor.TransactionAttributeEditor,供实现事务策略的手工编辑使用。借助于该属性编辑器,使自定义事务策略的过程更友好。上述配置内容的具体解释如下:
a)对于“get*”:这表明以get开头的业务方法(前提是,位于example11ServiceTarget中定义的JavaBean)必须处于事务中,这是通过PROPAGATION_REQUIRED限定的。如果调用客户不在事务上下文中,或者没有提供事务支持,则会创建新的事务。其中,readonly表明这是只读事务,这对于Hibernate而言特别有意义。
b)对于“set*”:这表明以set开头的业务方法(前提是,位于example11ServiceTarget中定义的JavaBean)必须处于事务中,这是通过PROPAGATION_REQUIRED限定的。如果调用客户不在事务上下文中,或者没有提供事务支持,则会创建新的事务。
c)其中设置的事务属性顺序并不重要,因为TransactionAttributeEditor会自动处理它们。比如PROPAGATION_REQUIRED,readOnly和readOnly,PROPAGATION_REQUIRED含义相同。
对于Spring提供的声明式事务支持,开发者能获得如下几方面的益处:
1)借助于Spring AOP提供了类似EJB CMT(容器事务管理)的功能。而且,能够对POJO进行事务性声明。
2)Spring提供的声明式事务能够适用于任何操作环境。比如,JDBC,Hibernate,JDO等,如果有新的事务性资源的加入,对于Spring应用而言,只需要修改下配置文件即可。
3)Spring还提供了声明式的回滚规则,比如,可以声明:如果某异常一旦抛出,事务必须回滚。比如,在事务属性中设置“-UserException”,则表明在事务处理过程中一旦出现UserException,则回滚当前事务。如设置“+UserException”,则表明在事务处理过程中一旦出现UserException,则提交当前事务。加号表示提交,减号表示回滚。这是很诱人的技术。
另外,Spring还提供了通过元数据(比如借助于Jakarta Commons Attributes)、指定方法名(org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource)、自动代理等方式定义事务策略。
2.2)[b]编程式事务[/b]
编程式事务比声明式事务更具灵活性。由于Spring AOP实现的拦截器只能拦截方法级的调用,因此如果需要事务支持,则整个方法处于事务中。如果存在遗留代码需要借助于Spring管理,则此时Spring可能不能够胜任。但无论如何,如果我们架构并设计新的企业应用系统,可以考虑到Spring的这种特性,更何况这是开发者大部分场合需要考虑的情况。
Spring为编程式事务提供了两种策略:
a)直接使用TransactionTemplate:这同JndiTemplate、JdbcTemplate、HibernateTemplate类似。由于TransactionTemplate是线程安全的,可以放心使用。
b)直接使用PlatformTransactionManager实现。开发者可以推导,TransactionTemplate一定需要PlatformTransactionManager实现,否则无法完成事务管理操作。因此,直接借助于PlatformTransactionManager实现一定能完成事务管理操作。当然,直接借助于PlatformTransactionManager实现事务管理,会比使用事务模版完成更多的设置和准备工作。
Spring team推荐:通常都最好使用TransactionTemplate
2.2.1)使用TransactionTemplate
Spring框架提供的、类似TransactionTemplate的模版有许多。它们是采用回调机制实现方法调用的。在方法调用期间,TransactionTemplate会将要求的资源准备好(调用开始)和释放掉(调用结束),这是模版的威力。在Spring中,所有模版都是线程安全的。
在使用TransactionTemplate之前,需要在Spring配置文件中进行配置。示例如下:
<bean id="transactionTemplate"
class="org.springframework.transaction.support.TransactionTemplate">
<property name="transactionManager">
<ref local="transactionManager"></ref>
</property>
</bean>
<bean id="transactionManager"
class="org.springframework.orm.hibernate.HibernateTransactionManager">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
</bean>
transactionManager是TransactionTemplate的属性,因此事务模版需借助Spring提供的事务管理器实现处理事务管理。事务模版可以使用Hibernate、JTA、JDBC、JDO等事务管理器。
[b]也可以基于TransactionTemplate的构建器来注入对事务管理器的依赖。[/b]接下来,开发者便能在java代码中直接使用TransactionTemplate了。依据Spring模版设计原则,Spring为TransactionTemplate准备了两个回调接口:TransactionCallback和TransactionCallbackWithoutResult。
a)org.springframework.transaction.support.TransactionCallback:用于事务的回调接口。通常,它都是伴随着TransactionTemplate并以匿名方式使用的。它仅含有单个方法,即doInTransaction。如果事务操作存在返回值,则使用TransactionCallback。如果不存在返回值,则使用TransactionCallbackWithoutResult接口。
b)org.springframework.transaction.support.TransactionCallbackWithoutResult:继承于TransactionCallback。TransactionCallbackWithoutResult供事务操作不存在返回值时使用。
对于存在返回值的业务方法而言,示例如下:
Object result = tt.execute(new TransactionCallback(){
public Object doInTransaction(TransactionStatus status){
try{
updateOperation1();
updateOperation2();
return updateOperation3();
}catch(RuntimeException ex){
status.setRollbackOnly();
}
return null;
}
});
其中,开发者需要实现Object doInTransaction(TransactionStatus status)方法。现在updateOperation1()、updateOperation2()、updateOperation3()都处于同一事务中,因此他们构成了ACID的特性。若出现异常,则事务回滚(借助于status的setRollbackOnly实现)。
对于不存在返回值的业务方法而言。示例如下:
Object result = tt.execute(new TransactionCallbackWithoutResult(){
public void doInTransactionWithoutResult(TransactionStatus status){
updateOperation1();
updateOperation2();
updateOperation3();
}
});
如果应用需要回滚,则需要调用TransactionStatus对象的setRollbackOnly方法。对于有EJB组件开发经验的人而言,能够看出这与CMT极其相似。
2.2.2)使用PlatformTransactionManager实现
借助于Spring IoC容器提供的控制反转,能够直接在应用代码中直接获得对<bean>元素中定义的PlatformTransactionManager实现。示例如下:
transactionManager = ...;
DefaultTransactionDefinition dtd = new DefaultTransactionDefinition();
dtd.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = transactionManager.getTransaction(dtd);
try{
updateOperation1();
updateOperation2();
updateOperation3();
}catch(ApplicationContext ex){
transactionManager.rollback(status);
throw ex;
}
注,上面的实现方式也是在模拟TransactionTemplate的行为,因此,[color=red]在编程式事务中,最好直接使用TransactionTemplate。[/color]