事务管理.doc

事务管理93068第 7 章 . Spring事务抽象Spring提供了一致的事务管理抽象。这个抽象是Spring最重要的抽象之一,它有如下的优点:为不同的事务API提供一致的编程模型,如JTA、JDBC、Hibernate、iBATIS数据库层和JDO提供比大多数事务API更简单的,易于使用的编程式事务管理API整合Spring数据访问抽象支持Spring声明式事务管理传统上,J2EE开发者有两个事务管理的选择:全局事务或局部事务。全局事务由应用服务器管理,使用JTA。局部事务是和资源相关的:例如,一个和JDBC连接关联的事务。这个选择有深刻的含义。全局事务可以用于多个事务性的资源(需要指出的是多数应用使用单一事务性的资源)。使用局部事务,应用服务器不需要参与事务管理,并且不能帮助确保跨越多个资源的事务的正确性。全局事务有一个显著的不利方面,代码需要使用JTA:一个笨重的API(部分是因为它的异常模型)。此外,JTA的UserTransaction通常需要从JNDI获得,这意味着我为了JTA需要同时使用JNDI和JTA。显然全部使用全局事务限制了应用代码的重用性,因为JTA通常只在应用服务器的环境中才能使用。使用全局事务的比较好的方法是通过EJB的CMT(容器管理的事务):声明式事务管理的一种形式(区别于编程式事务管理)。EJB的CMT不需要任何和事务相关的JNDI查找,虽然使用EJB本身肯定需要使用JNDI。它消除大多数——不是全部——书写Java代码控制事务的需求。显著的缺点是CMT绑定在JTA和应用服务器环境上,并且只有我们选择使用EJB实现业务逻辑,或者至少处于一个事务化EJB的外观(Facade)后才能使用它。EJB有如此多的诟病,当存在其它声明式事务管理时,EJB不是一个吸引人的建议。局部事务容易使用,但也有明显的缺点:它们不能用于多个事务性资源,并且趋向侵入的编程模型。例如,使用JDBC连接事务管理的代码不能用于全局的JTA事务中。Spring解决了这些问题。它使应用开发者能够使用在任何环境下使用一致的编程模型。你可以只写一次你的代码,这在不同环境下的不同事务管理策略中很有益处。Spring同时提供声明式和编程式事务管理。使用编程式事务管理,开发者直接使用Spring事务抽象,这个抽象可以使用在任何底层事务基础之上。使用首选的声明式模型,开发者通常书写很少的事务相关代码,因此不依赖Spring或任何其他事务API。. 事务策略Spring事务抽象的关键是事务策略的概念。这个概念由接口体现,如下:publicinterfacePlatformTransactionManager{TransactionStatusgetTransaction(TransactionDefinitiondefinition)throwsTransactionException;mit(TransactionStatusstatus)throwsTransactionException;voidrollback(TransactionStatusstatus)throwsTransactionException;}这首先是一个SPI接口,虽然它也可以在编码中使用。注意按照Spring的哲学,这是一个接口。因而如果需要它可以很容易地被模拟和桩化。它也没有和一个查找策略如JNDI捆绑在一起:PlatformTransactionManager的实现定义和其他SpringIoC容器中的对象一样。这个好处使得即使使用JTA,也是一个很有价值的抽象:事务代码可以比直接使用JTA更加容易测试。继续Spring哲学,TransactionException是unchecked的。低层的事务失败几乎都是致命。很少情况下应用程序代码可以从它们中恢复,不过应用开发者依然可以捕获并处理TransactionException。getTransaction()根据一个类型为TransactionDefinition的参数返回一个TransactionStatus对象。返回的TransactionStatus对象可能代表一个新的或已经存在的事务(如果在当前调用堆栈有一个符合条件的事务)。如同J2EE事务上下文一样,一个TransactionStatus也是和执行的线程关联的。TransactionDefinition接口指定:事务隔离:当前事务和其它事务的隔离的程度。例如,这个事务能否看到其他事务未提交的写数据?事务传播:通常在一个事务中执行的所有代码都会在这个事务中运行。但是,如果一个事务上下文已经存在,有几个选项可以指定一个事务性方法的执行行为:例如,简单地在现有的事务中运行(大多数情况);或者挂起现有事务,创建一个新的事务。Spring提供EJBCMT