spring事务管理Word文档下载推荐.docx
《spring事务管理Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《spring事务管理Word文档下载推荐.docx（13页珍藏版）》请在冰豆网上搜索。
在软件开发的一个重要传统里，可以用一个单词首字母的缩写来描述一个事务：
ACID，简言之，ACID代表
Atomic（原子性）事务由一个或多个动作绑定起来作为一个单独的工作单元。
原子性保证事务中所有的操作要么都执行，或者都不执行。
如果所有的动作都执行了，那么事务就是成功的，如果其中有一个动作失败了，那么整个事务都失败，而且要执行回滚操作。
Consistent（一致性）一旦事务结束（可能成功了也可能失败了），那么系统所模拟的业务逻辑要处于一致的状态。
数据不应该被实体关系破坏。
Isolated（隔离性）事务应该允许多个用户操作一个数据，一个用户的操作应该不受另一个用户操作的影响。
因此事务之间应该是相互隔离的，以阻止他们在操作中同时读写同一数据。
（一般是以乐观锁来实现这一特性的）
Durable（持久性）一旦事务完成，事务执行的结果就应该被保存到数据库中，这样即使因为某一原因系统崩了，数据还能保存下来。
传统上是把结果保存到数据库或者其他某种格式的持久化介质中。
在刚才的电影票的例子中，如果任何一个步骤失败的话事务可以所有取消操作的结果来保证原子性。
原子性可以通过保证系统的数据从来没有不一致的状态，和从来没有部分执行的状况来保证一致性。
隔离性可以通过阻止其他并发事务在你正在购买你的座位的时候把这个座位从你那里偷走来保证一致性。
最终的效果就是持久性，因为它们已经被保存到存储介质中去了。
如果系统崩了或有其他类似的事件发生的话你也不需要担心事务的结果会丢失。
如果需要更详细的解释，我们建议你看看MartinFowler写的PatternsofEnterpriseApplicationArchitecture。
尤其是第五章，讨论了并发和事务。
5.1.2理解spring对事务处理的支持
和ejb一样，spring也提供了对包括的两种事务的支持，但是spring的事务管理能力超过了ejb的事务管理能力。
Spring对代码级事务管理的支持很大程度上不同于ejb。
与ejb不同的是，ejb和jta实现是联系在一起的，spring使用的是一种招回机制以从从事务代码种抽象出真实的事务实现。
事实上，spring的事务管理甚至不需要一个jta的实现。
如果你的应用程序只使用一个单一的持久资源，那么你就可以使用持久机制提供的事务支持来处理你的事务。
这包括jdbc，hibernate，jdo和ojb。
然而，如果你的程序有涉及到多个资源的事务需求，spring可以用第三方的jta实现来提供一个分布式的事务支持。
在5.2种我们将讨论spring对代码级事务管理的支持。
在你的代码中，代码级事务管理提供给你精确的弹性来定义的事务边界，声明式事务在其事务规则中帮助你减弱了操作带来的影响。
Spring对声明式事务处理的支持让我们想起了ejb的容器管理事务（cmt）。
两者都允许你们显式的定义事务的边界。
但是spring的声明式事务超出了cmt，因为它允许你声明附加的属性，比如说隔离级别和timeouts。
在5.3中我们将阐述spring的声明式事务管理。
选择代码级事务管理还是声明式事务管理就决定了你是选择了对程序（fine-grained）严密的控制还是选择了方便。
当你把事务编写到你的代码中时，你就可以精确的控制事务的边界，在你需要的地方精确的开始和结束事务。
一般的做法是，你不需要代码级提供的对程序的精密的控制时就选择把你的事务声明到一个上下文环境中去（就是说选择声明式事务管理）。
不管你是否选择把事务写到你的bean中还是当作一个切面来声明它们，你将使用一个spring的事务管理来作为接口插入到平台具体的事务实现中。
让我们看一下spring的事务管理是如何用平台的具体的事务实现把你从事务处理中解放出来的。
5.1.3介绍spring的事务管理
Spring并没有直接管理事务，取而代之的是，它提供了另一个选择，把事务管理部分的责任委托给平台具体的事务实现，这些事务实现可能是jta提供的或者也可以是持久机制提供的。
这里我们将着重介绍spring对hibernate的事务支持。
Hibernate的事务
如果你的程序是用hibernate来实现持久化的，那么你要使用HibernateTransactionManager这个类。
用下面提供的xml文件来在程序中声明这个类。
sesssionFactory这个property应该填上一个hibernate的SessionFactory，这里最好取名为sessionFactory。
上面有如何创建一个hibernate的SessionFactory的详细的讲解。
HibernateTransactionManager把事务管理的责任委托给一个net.sf.hibernate.Transaction对象，这个对象可以hibernate的session对象得到。
类似的，当一个事务失败了，事务对象就会调用rollback（）这个方法执行回滚操作。
5.2在spring中开发事务处理程序
CourseService类的enrollStudentInCourse（）方法在一个学生注册一门课程的过程中要执行多个步骤，如果其中的任何一个步骤出错，那么所有的操作都必须回滚到改方法执行前的状态。
换句话说，enrollStudentInCourse（）方法必须要用事务包装起来。
把事务加到你的代码中的途径之一就是利用spring的TransactionTemplate类把事务边界以代码的形式写到程序中。
就像spring中的其他模板类一样，TransactionTemplate使用了一个招回机制。
下面的代码告诉你怎么用TransactionTemplate来包装你的代码。
PublicvoidenrollStudentInCourse（）{
transactionTemplate.execute（newTransactionCallback（）{
publicObjectdoInTransaction（TransactionStatusts）{
try{
//dostuff<
-RunswithindoInTransaction（）
}catch（Exceptine）{
Ts.setRollbackOnly（）;
<
-CallssetRollbackOnly（）torollback
}
Returnnull;
-ifsuccessfultransactioniscommitted
}）;
你以实现TransactionCallback接口为开始。
因为TransactionCallback只需要实现一个方法，作为一个匿名内部类来说实现这个方法通常是最简单的。
把这些代码放在doInTransaction（）方法中的上下文事务环境中，再把这个doInTransaciton方法放在你的程序要执行上面这些代码的地方（不理解就看上面这段代码是怎么做的）。
在TransactionTemplate实例中使用execute（）方法将执行包含在TransactionCallback实例中的代码。
如果你的代码遇到问题，那么调用TransactionStatus对象的setRollbackOnly（）方法将回滚事务。
否则，如果doInTransaction（）方法成功返回的话，事务将会被提交。
TransactionTemplate实例是怎么得到的呢？
这是一个不错的疑问，它应该被注入到CourseServiceImpl类中，像下面那样：
注意一下，transactionTemplate这个bean有一个transactionManager的property（属性）。
隐藏在表象之下的是，TransactionTemplate使用了一个PlatformTransactionManager（这是一个接口）的实现来处理平台具体的事务管理的细节。
这里我们注册了一个名为transactionManager的bean的引用，这个bean可以是任意一种PlatformTransactionManager接口的实现（比如说DataSourceTransactionManager,HibernateTransactionManager,JdoTransactionManager,JtaTransactionManager,或者是PersistenceBrokerTransactionManager）。
当你需要完全控制事务边界的时候代码级事务管理是很好的。
但是，正如你上面所看到的，这样做有点烦，你不得不更改enrollStudentInCourse（）方法的实现，为了得到spring的代码级事务的支持你不得不使用spring的具体的类。
通常你的事务需求不需要那么精密的控制事务边界。
那就是为什么一般你选择在程序外面声明你的事务的原因了（比如说在spring的配置文件中）。
下面我们将要讲解spring的声明式事务管理。
5.3声明事务
在不久之前，声明式事务管理只有在ejb容器中才能实现。
但是现在spring也提供了对pojo的声明式事务管理的支持。
这是一个spring的一个意义重大的特性，因为你的应用程序不再只是因为要得到声明式原子性操作而需要复杂而且重量级的ejb了。
Spring对声明式事务的支持实际上是spring的aop框架的一个实现。
Aop显然很适合来实现声明式事务管理，因为事务是系统级的服务，应该是在应用程序主功能的上面一层。
你可以把spring的事务认作是包装了一个方法的切面。
为了在你的应用程序中使用声明式的事务，你要用TransactionProxyFactoryBean这个类。
这个动态工厂bean类似ProxyFactoryBean，不一样的是这个bean在上下文事务环境中包装方法是有一个具体的目的的。
你也可以自己创建一个ProxyFactoryBean来处理事务，但是用TransactionProxyFactoryBean更简单，因为它是专门为处理声明式事务而设计的。
下面将告诉你如何声明一个TransactionProxyFactoryBean：
Com.springinaction.training.service.CourseService////interfaceimplementedbyproxy
////beanbeingproxied
/////transactionmanager
////transactionattributesource
注意一下,这个bean有一个courseService的id。
这是为了当应用程序需要得到一个courseService时，那么可以从应用程序上下文环境中得到被TransactionProxyFactoryBean包装过的courseService实例。
原来的courseServicebean应该重命名一下，避免和bean的id冲突。
任何名字都可以，但是把目标bean的名字取成“目标bean的代理＋Target“这种格式是一个约定成俗的规定。
所以，courseServiceTarget是合适的：
除了它的目标bean之外，TransactionProxyFactoryBean还有两个合作者。
transactionManager这个property暗示着一个使用明确的上下文事务环境的PlatformTransactionManager的实例。
这个PlatformTransactionManager可以是任何一个具体TransactionManager。
而transactionAttributeSource这个property是一个TransactionAttributeSource这个bean的引用。
为了理解transactionattributesources的工作原理，你必须先要理解transactionattributes。
那么，让我们来仔细看一下transactionattribute是怎么工作的吧。
5.3.1理解事务的属性（transactionattributes）
在spring中，一个transactionattribute是事务方针如何作用在一个方法上的一种描述。
这种描述可以包括一种或是多种以下的参数
Propagationbehavior（传播行为）
Isolationlevel（隔离级别）
Read-onlyhints（只都标示）
Thetransactiontimeoutperiod（失效周期）
传播行为在尊重客户端和调用的方法的基础上来定义事务的边界的。
Spring定义了7种截然不同的传播行为，如下表所列：
1PROPAGATION_NOT_SUPPORTED
表示方法没有事务需求，如果在方法的执行过程前已经有一个已存在的事务，那么在方法的执行过程中，该事务应该暂停。
如果使用的是
JTATransactionManager的话，必须要有权使用TransactionManager类
2PROPAGATION_REQUIRED
表示当前的方法有事务需求。
如果在方法执行前已经存在一个事务，那么这个方法将在这个事务中执行。
否则就开始一个新的事务。
3PROPAGATION_REQUIRES_NEW
表示当前的方法必须在自己的事务中运行。
一个新的事务会开始，而且如果方法执行之前已经有事务存在，那么这个事务在方法执行的过程中会暂停。
如果使用JTATransactionManager的话，有权使用TransactionManager类是必须的。
4PROPAGATION_SUPPORTS
表示当前方法不需要上下文事务环境，但可以运行在方法执行之前已经存在的事务中。
5PROPAGATION_MANDATORY
表示方法必须运行在一个事务中，如果没有这样一个事务，将会抛出异常。
6PROPAGATION_NESTED
表示如果在进程中已经存在一个事务，那么这个方法应该运行在一个嵌套事务之中。
一个嵌套的事务可以从放入该嵌套的事务处单独的提交或回滚，如果没有事务在嵌套事务中，那就要有PROPAGATION_REQUIRED的行为。
要注意这种传播行为是问题最多的。
为你的资源管理者参考一下文档然后决定是否支持嵌套事务。
7PROPAGATION_NEVER
表示当前的方法不应该在一个上下文事务环境中运行。
如果有这么一个事务在进程中的话，将会抛出异常。
上面大多数的传播行为看上去是很熟悉的。
那是因为它们反映出了ejb中容器事务管理（cmt）的传播规则。
比如，spring的PROPAGATION_REQUIRES_NEW相当与cmt的requiresNew.spring加了一个cmt中没有的传播行为，PROPAGATION_NESTED，这样做是为了能支持嵌套事务。
一个新的事务是否应该创建或者暂停，或者一个方法是否应该在一个上下文事务环境中执行，这都是一个问题，而传播规则则从根本上回答了这些问题。
举个例子，如果一个方法被声明成PROPAGATION_REQUIRES_NEW这个传播行为，这就意味者事务边界和方法自己的边界是一样的：
当方法开始时事务就开始了，当方法返回或者是抛出了异常那么事务就结束。
如果方法被声明成PROPAGATION_REQUIRED，那么事务的边界取决于一个事务是否已经在运行中。
Isolationlevels隔离级别
在一个典型的应用程序中，多事务并发是很平常的，它们经常操作同一数据而且完成自己的工作。
并发是必需的，但是可能导致以下的问题：
Dirtyread（脏读）
当一个事务在读取数据，但这个数据已经被另一个事务改写但是该事务还是没有提交（就是说这个事务还没有结束），这时候就会发生脏读。
如果这个改动待会被回滚，那么第一事务所持有的数据将是无效的。
Nonrepeatableread（不可重复读）
当一个事务执行同一个查询命令时两次以上，但是每次查询的数据都不一样，不可重复读就发生了。
者通常是因为另外一个并发的事务在几次查询之间正在更新数据造成的。
Phantomreads（虚读）
虚读类似于不可重复读。
当事务T1读了几行数据，然后另一个并发的事务T2插入了几行。
在后来的查询中，T1发现以前不存在的那些行。
在一个理想的情况下，事务应该相互完全隔离，阻止这些问题的发生。
然而，完全的隔离会影响性能，因为它涉及到在数据库中把行（row）锁住（有时会是锁住整张表（table））。
带有侵略性的锁会阻碍并发，要求事务相互等待来完成它们的工作（不会是死锁吧，呵呵）。
认识到完全的隔离会影响到性能，而且不是所有的应用程序都需要完全的隔离，在对待事务隔离这个问题上，有时要求一些弹性也是合理的。
因此有如下几种隔离级别：
1ISOLATION_DEFAULT
使用数据存储系统默认的隔离级别
2ISOLATION_READ_UNCOMMITTED
在一个事务没有被提交之前允许你读取该事务改变过的数据，但可能导致脏读虚读和不可重复读
3ISOLATION_READ_COMMITTED
允许从已提交的并发事务中读取。
脏读是被禁止的，但是虚读和不可重复都是可以的
4ISOLATION_REPEATABLE_READ
多次读取同一个域会产生相同的结果，除非被事务自己改变了。
脏读和不可重复读是被禁止的，虚读可以发生。
5ISOLATION_SERIALIZABLE
这个完全的适应acid的隔离级别保证了脏读，不可重复读，和虚读都被禁止，这个是所有隔离级别中最缓慢的一种，因为它很具代表性的在涉及到事务的所有表上都加了锁（对表加的锁）。
ISOLATION_READ_UNCOMMITTED是最有效的隔离级别，但是只是最小程度的隔离了事务，把事务向脏读，不可重复读和虚读开放了。
另一个极端，ISOLATION_SERIALIZABLE防止了所有隔离问题的形式，但是，效率是最低的。
要知道并不是所有的资源管理器都支持上面所列的隔离级别。
参考你的资源管理器的文档来决定那些隔离级别是允许的。
Read-only
如果事务只对应底层数据仓库只执行都操作，那么数据仓库也许可以利用事务只读的特性来执行某些优化。
通过把一个事务声明成read-only，你可以给底层数据仓库机会去应用那些优化措施，而这些措施是数据仓库确定对优化来说是合适。
因为read-only的优化是当一个事务开始时由底层数据仓库来应用的，它只对那些把事务声明成read-only这个传播行为的方法才有意义，这个传播行为可能会开始一个新的事务（PROPAGATION_REQUIRED,PROPAGATION_REQUIRES_NEW,PROPAGATION_NESTED）.
此外，如果你使用hibernate作为你的持久机制，把一个事务声明成read-only的话会导致hibernate中的flush模式被设成FLUSH_NEVER。
这样就告诉了hibernate要用数据库来避免对象的非必须的同步。
延迟所有的更新直到事务结束。
Transactiontimeout
最后，还有一个你可以选择来设置事务属性的是timeout。
假设你的事务运行的时间变的长的出人意料。
因为事务涉及到对底层数据仓库的锁，所以长时间的事务运行可能会占用数据库资源，而这种占用有不是必须的。
你可以声明一个事务在一定的秒数之后自动回滚，而不是等它执行结束。
因为timeout是从事务开始的时候开始算起的，它只对那些用传播行为在方法上把事务声明成timeout才有意义，这个传播行为可能会开始一个新的事务（PROPAGATION_REQUIRED,PROPAGATION_REQUIRES_NEW,PROPAGATION_NESTED）。
5.3.2声明一个简单事务的策略
TransactionProxyFactoryBean参考一个方法的事务的属性来决定怎样管理那个方法上的事务策略。
但是TransactionProxyFactoryBean从哪里得到一个方法的事务属性的呢。
如你所见，TransactionProxyFactoryBean有一个transactionAttributeSource的property。
这个property就代表着一个TransactionAttributeSource的实例。
一个TransactionAttributeSource就是作为一个引用来查找设置在方法上的事务属性的。
一个TransactionAttributeSource就是由下面的接口来定义的：
publicinterfaceTransactionAttributeSource{
publicTransactionAttributegetTransactionAttribute（
java.lang.reflect.Methodmethod,
java.lang.ClasstargetClass）;
getTransactionAttribute这个方法用来为一个特定的方法寻找其事务的属性，前提是给出目标类和方法。
这个TransactionAttribute返回的就表示着事务策略应该被应用到方法上。
现在让我们在应用程序的xml配置文件中定义一下transactionAttributeSource这个bean，如下：
瞧，随这个transactionAttributeSource这个bean的声明，所有由TransactionProxyFactoryBean的目标类来代理的方法都在一个上下文事务环境中执行了。
但是要注意你没有具体指定哪个方法需要事务，或者甚至没有指定要应该什么样的事务策略。
因为我们决定在这里用MatchAlwaysTransactionAttributeSource这个类。
MatchAlwaysTransactionAttributeSource可能是TransactionAttributeSource这个接口最简单的实现了。
当这个类的getTransactionAttribute（）方法被调用，它每次都会返回同样的TransactionAttribute，不管方法被包装在什么样的事务中（一般来说是：
PROPAGATION_REQUIRED和ISOLATION_DEFAU
升级会员 