Spring TransactionDefinition接口

http://www.cnblogs.com/fengchaowang/p/4122579.html

16.2.1　探索TransactionDefinition接口

正如之前所说的，TransactionDefinition接口控制着事务的属性。下面让我们进一步看看该接口及其方法，如代码清单16-1所示：

代码清单16-1　TransactionDefinition接口

接口中简单而明显的方法是getTimeout()方法，它返回一个事务必须完成的时间限制（以秒为单位），还有isReadOnly()方法，它表示事务是否只读。事务管理器的实现可以利用这个值来优化事务的执行，并确保事务只进行读取操作。

另外两个方法--getPropagationBehavior()与getIsolationLevel()需要深入讨论。我们先介绍getIsolationLevel()，它对其他事务所能看到的数据变化进行控制。表16-1列出了你可以使用的事务隔离级别，并说明了其他事务可以访问的当前事务变化。

表16-1　事务隔离级别

隔离级别	说明
TransactionDefinition.ISOLATION_DEFAULT	PlatformTransactionManager的默认隔离级别（对大多数数据库来说就是ISOLATION_ READ_COMMITTED）
TransactionDefinition.ISOLATION_READ_UNCOMMITTED	最低的隔离级别。事实上我们不应该称其为隔离级别，因为在事务完成前，其他事务可以看到该事务所修改的数据。而在其他事务提交前，该事务也可以看到其他事务所做的修改
TransactionDefinition.ISOLATION_READ_COMMITTED	大多数数据库的默认级别。在事务完成前，其他事务无法看到该事务所修改的数据。遗憾的是，在该事务提交后，你就可以查看其他事务插入或更新的数据。这意味着在事务的不同点上，如果其他事务修改了数据，你就会看到不同的数据
TransactionDefinition.ISOLATION_REPEATABLE_READ	比ISOLATION_READ_COMMITTED更严格，该隔离级别确保如果在事务中查询了某个数据集，你至少还能再次查询到相同的数据集，即使其他事务修改了所查询的数据。然而如果其他事务插入了新数据，你就可以查询到该新插入的数据
TransactionDefinition.　ISOLATION_SERIALIZABLE	代价最大、可靠性最高的隔离级别，所有的事务都是按顺序一个接一个地执行

选择合适的隔离级别对于保证数据的一致性非常重要，并且所作出的选择会对性能产生重大影响。最高的隔离级别TransactionDefinition.ISOLATION_SERIALIZABLE开销最大。

getPropagationBehavior()方法指定了当代码请求一个新的事务时Spring所做的事情。表16-2列出了这个方法的常量值。

表16-2　传播行为值

传播行为	说明
TransactionDefinition.PROPAGATION_REQUIRED	当前如果有事务，Spring就会使用该事务；否则会开始一个新事务
TransactionDefinition.PROPAGATION_SUPPORTS	当前如果有事务，Spring就会使用该事务；否则不会开始一个新事务
TransactionDefinition.PROPAGATION_MANDATORY	当前如果有事务，Spring就会使用该事务；否则会抛出异常
TransactionDefinition.PROPAGATION_REQUIRES_NEW	Spring总是开始一个新事务。如果当前有事务，则该事务挂起
TransactionDefinition.PROPAGATION_NOT_SUPPORTED	Spring不会执行事务中的代码。代码总是在非事务环境下执行，如果当前有事务，则该事务挂起
TransactionDefinition.　PROPAGATION_NEVER	即使当前有事务，Spring也会在非事务环境下执行。如果当前有事务，则抛出异常
TransactionDefinition.　PROPAGATION_NESTED	如果当前有事务，则在嵌套事务中执行。如果没有，那么执行情况与Transaction- Definition.PROPAGATION_REQUIRED一样

 

 

16.2.2　使用TransactionStatus接口

如代码清单16-2所示，TransactionStatus接口可以让事务管理器控制事务的执行，可以检查事务是不是一个新事务，或者是否只读。TransactionStatus还可以初始化回滚操作。

代码清单16-2　TransactionStatus 声明

TransactionStatus接口中的方法很容易理解；最引人注目的就是setRollbackOnly()，它将一个事务标识为不可提交的。换句话说，在调用完setRollbackOnly()后你所能执行的唯一操作就是回滚。在大多数情况下，事务管理器会检测到这一点，在它发现事务要提交时会立刻结束事务。代码清单16-3中的伪代码说明了这一点。

代码清单16-3　setRollbackOnly()方法的使用

在调用完setRollbackOnly()后，大多数数据库可以继续执行下一条select语句，但不允许执行update语句--执行update是没有意义的，因为事务只可以进行读取操作，任何修改都不会被提交。

 

 

16.2.3　PlatformTransactionManager的实现

PlatformTransactionManager接口使用TransactionDefinition和TransactionStatus接口，创建并管理事务。该接口的实现必须对事务管理器有深入理解。DataSourceTransactionManager控制着从DataSource中获得的JDBC Connection上的事务的执行；HibernateTransactionManager控制着Hibernate session上的事务的执行；JdoTransactionManager管理着JDO事务；JtaTransactionManager将事务管理委托给JTA。

 

16.3　对一个事务管理示例的探索（1）

本章的第一部分已经对Spring中的事务基础架构进行了概览，但我们认为，仍然需要给出一个能说明如何使用Spring的事务支持的示例。

使用事务操作的方式有3种基本方式：可以使用声明式事务，只需声明某个方法需要事务就行了；可以使用源码级的元素据来说明某个方法需要一个事务；还可以用编写事务代码的方式来实现。Spring对这3种方式都提供了支持，我们从最灵活最方便的方式开始，即声明式事务管理。

首先我们将展示几种事务支持的实现方式。浏览一下图16-1中的UML类图，对该示例应用中需要保存的数据有一个直观印象。

尽管该类图看起来有些复杂，但我们只是实现一个简单的银行应用程序。我们有一个用来维护账户余额的Account类（这是真实银行账户的简化版，但对于示例来说足够用了）。我们将AccountIdentity作为银行账户的唯一标识。BalanceMutator接口只有一个mutate(BigDecimal)方法，我们在BankService- Support中实现该接口。CreditBalanceMutator将贷款数额加到了balance参数中。DebitBalanceMutator稍微有点复杂，它检查账户中是否有足够的钱可以借出。若想进一步探究这个概念，例如可以修改DebitBalanceMutator以允许透支。

AccountDao定义了一个数据访问接口，该接口由JdbcAccountDao类实现。接下来，我们在BankService接口中定义了transfer和getBalance方法。BankServiceSupport实现了这两个方法，它用两个以do开头的protected方法进行实现。我们将使用BankServiceSupport子类来演示各种不同的事务管理技术。

（点击查看大图）图16-1　带有事务的银行应用示例的UML类图

非事务性代码

在讨论事务管理之前，我们得编写必要的支持代码。让我们以代码清单16-4中的SQL代码开始吧，这些代码创建了t_account表并插入几个测试账户。

代码清单16-4　样例账户应用的SQL 代码

这些SQL代码没什么特别的。如果你没有使用Oracle 10g数据库，那么你可能需要修改一下SQL语法使之适合你的数据库。接下来，我们看看Account与AccountIdentity类及BalanceMutator接口。我们在代码清单16-5中列出了这几个类和接口的代码。

代码清单16-5　Account、AccountIdentity和BalanceMutator

你可以看到Account类有一个我们赋予的识别器（Long id）。该识别器就是实现的细节问题了：我们的代码需要这个ID，但它对用户来说是没有任何意义的。用户使用账户号和分类号来标识其账户。Account类只有一个重要的方法：changeBalance(BalanceMutator)。这个方法使用BalanceMutator实例来更新账户的余额。

说明 我们选择使用BalanceMutator来更新账户的余额，因为我们觉得管理余额的规则可能会非常复杂。使用一个接口（该接口在服务层实现）会比在Account类中简单地定义credit(BigDecimal)和debit(BigDecimal)方法更灵活。

接下来，我们看看该示例应用的数据访问层。简单起见，我们使用SimpleJdbcTemplate（请查看第9章以了解关于Spring JDBC支持的详细内容）。我们采取了Spring应用所使用的一种典型方式：创建AccountDao接口及其实现--JdbcAccountDao。代码清单16-6列出了接口和实现的源代码。

代码清单16-6　AccountDao接口和JdbcAccountDao实现

我们尽量保持代码的简单性。记住我们并不是在展示Spring JDBC，而仅仅是实现数据访问层代码以说明Spring的事务管理。最后，我们实现了BankServiceSupport，将该类作为事务性的BankService实现的父类。这样，BankServiceSupport就用以do开头的protected方法去实现BankService中的方法。代码清单16-7显示了BankServiceSupport的实现。

代码清单16-7　BankServiceSupport代码