标签:des style class blog code java
事务首先是一系列操作组成的工作单元,该工作单元内的操作是不可分割的,即要么所有操作都做,要么所有操作都不做,这就是事务。
事务必需满足ACID(原子性、一致性、隔离性和持久性)特性,缺一不可:
在实际项目开发中数据库操作一般都是并发执行的,即有多个事务并发执行,并发执行就可能遇到问题,目前常见的问题如下:
为了解决这些并发问题,需要通过数据库隔离级别来解决,在标准SQL规范中定义了四种隔离级别:
隔离级别越高,数据库事务并发执行性能越差,能处理的操作越少。因此在实际项目开发中为了考虑并发性能一般使用提交读隔离级别,它能避免丢失更新和脏读,尽管不可重复读和幻读不能避免,但可以在可能出现的场合使用悲观锁或乐观锁来解决这些问题。
数据库事务类型有本地事务和分布式事务:
Java事务类型有JDBC事务和JTA事务:
Java EE事务类型有本地事务和全局事务:
按是否通过编程实现事务有声明式事务和编程式事务;
Spring框架最核心功能之一就是事务管理,而且提供一致的事务管理抽象,这能帮助我们:
Spring支持声明式事务和编程式事务事务类型。
Spring框架支持事务管理的核心是事务管理器抽象,对于不同的数据访问框架(如Hibernate)通过实现策略接口PlatformTransactionManager,从而能支持各种数据访问框架的事务管理,PlatformTransactionManager接口定义如下:
TransactionDefinition接口定义如下:
TransactionStatus接口定义如下:
Spring提供了许多内置事务管理器实现:
Spring不仅提供这些事务管理器,还提供对如JMS事务管理的管理器等,Spring提供一致的事务抽象如图9-1所示。
图9-1 Spring事务管理器
接下来让我们学习一下如何在Spring配置文件中定义事务管理器:
一、声明对本地事务的支持:
a)JDBC及iBATIS、MyBatis框架事务管理器
通过dataSource属性指定需要事务管理的单个javax.sql.DataSource对象。
b)Jdo事务管理器
通过persistenceManagerFactory属性指定需要事务管理的javax.jdo.PersistenceManagerFactory对象。
c)Jpa事务管理器
通过entityManagerFactory属性指定需要事务管理的javax.persistence.EntityManagerFactory对象。
还需要为entityManagerFactory对象指定jpaDialect属性,该属性所对应的对象指定了如何获取连接对象、开启事务、关闭事务等事务管理相关的行为。
d)Hibernate事务管理器
通过entityManagerFactory属性指定需要事务管理的org.hibernate.SessionFactory对象。
二、Spring对全局事务的支持:
a)Jta事务管理器
“dataSource”Bean表示从JNDI中获取的数据源,而txManager是JTA事务管理器,其中属性transactionManagerName指定了JTA事务管理器的JNDI名字,从而将事务管理委托给该事务管理器。
这只是最简单的配置方式,更复杂的形式请参考Spring Javadoc。
在此我们再介绍两个不依赖于应用服务器的开源JTA事务实现:JOTM和Atomikos Transactions Essentials。
对于以上JTA事务管理器使用,本文作者只是做演示使用,如果在实际项目中需要不依赖于应用服务器的JTA事务支持,需详细测试并选择合适的。
在本文中将使用Atomikos Transactions Essentials来进行演示JTA事务使用,由于Atomikos对hsqldb分布式支持不是很好,在Atomikos官网中列出如下兼容的数据库:Oracle、Informix、FirstSQL、DB2、MySQL、SQLServer、Sybase,这不代表其他数据库不支持,而是Atomikos团队没完全测试,在此作者决定使用derby内存数据库来演示JTA分布式事务。
1、首先准备jar包:
1.1、准备derby数据jar包,到下载的spring-framework-3.0.5.RELEASE-dependencies.zip中拷贝如下jar包:
com.springsource.org.apache.derby-10.5.1000001.764942.jar
1.2、准备Atomikos Transactions Essentials 对JTA事务支持的JTA包,此处使用AtomikosTransactionsEssentials3.5.5版本,到官网下载AtomikosTransactionsEssentials-3.5.5.zip,拷贝如下jar包到类路径:
atomikos-util.jar
transactions-api.jar
transactions-essentials-all.jar
transactions-jdbc.jar
transactions-jta.jar
transactions.jar
将如上jar包放在lib\atomikos目录下,并添加到类路径中。
2、接下来看一下在Spring中如何配置AtomikosTransactionsEssentials JTA事务:
2.1、配置分布式数据源:
在此我们配置两个分布式数据源:使用com.atomikos.jdbc.AtomikosDataSourceBean来配置AtomikosTransactionsEssentials分布式数据源:
在此我们还有定义了一个“dataSource2”Bean,其属性和“DataSource1”除以下不一样其他完全一样:
2.2、配置事务管理器:
配置完毕,是不是也挺简单的,但是如果确实需要使用JTA事务,请首先选择应用服务器事务管理器,本示例不适合生产环境,如果非要运用到生产环境,可以考虑购买AtomikosTransactionsEssentials商业支持。
b)特定服务器事务管理器
Spring还提供了对特定应用服务器事务管理器集成的支持,目前提供对IBM WebSphere、BEA WebLogic、 Oracle OC4J应用服务器高级事务的支持,具体使用请参考Spring Javadoc。
现在我们已经学习如何配置事务管理器了,但是只有事务管理器Spring能自动进行事务管理吗?当然不能了,这需要我们来控制,目前Spring支持两种事务管理方式:编程式和声明式事务管理。接下来先看一下如何进行编程式事务管理吧。
所谓编程式事务指的是通过编码方式实现事务,即类似于JDBC编程实现事务管理。
Spring框架提供一致的事务抽象,因此对于JDBC还是JTA事务都是采用相同的API进行编程。
此处可以看到使用UserTransaction而不是Connection连接进行控制事务,从而对于JDBC事务和JTA事务是采用不同API进行编程控制的,并且JTA和JDBC事务管理的异常也是不一样的。
具体如何使用JTA编程进行事务管理请参考cn.javass.spring.chapter9包下的TranditionalTransactionTest类。
而在Spring中将采用一致的事务抽象进行控制和一致的异常控制,即面向PlatformTransactionManager接口编程来控制事务。
Spring中的事务分为物理事务和逻辑事务;
逻辑事务即支持非常低级别的控制,也有高级别解决方案:
工具类:使用工具类获取连接(会话)和释放连接(会话),如使用org.springframework.jdbc.datasource包中的 DataSourceUtils 类来获取和释放具有逻辑事务功能的连接。当然对集成第三方ORM框架也提供了类似的工具类,如对Hibernate提供了SessionFactoryUtils工具类,JPA的EntityManagerFactoryUtils等,其他工具类都是使用类似***Utils命名;
TransactionAwareDataSourceProxy:使用该数据源代理类包装需要Spring事务管理支持的数据源,该包装类必须位于最外层,主要用于遗留项目中可能直接使用数据源获取连接和释放连接支持或希望在Spring中进行混合使用各种持久化框架时使用,其内部实际使用 DataSourceUtils 工具类获取和释放真正连接;
通过如上方式包装数据源后,可以在项目中使用物理事务编码的方式来获得逻辑事务的支持,即支持直接从DataSource获取连接和释放连接,且这些连接自动支持Spring逻辑事务;
模板类:使用Spring提供的模板类,如JdbcTemplate、HibernateTemplate和JpaTemplate模板类等,而这些模板类内部其实是使用了低级别解决方案中的工具类来管理连接或会话;
Spring提供两种编程式事务支持:直接使用PlatformTransactionManager实现和使用TransactionTemplate模板类,用于支持逻辑事务管理。
如果采用编程式事务推荐使用TransactionTemplate模板类和高级别解决方案。
首先让我们看下如何使用PlatformTransactionManager实现来进行事务管理:
1、数据源定义,此处使用第7章的配置文件,即“chapter7/ applicationContext-resources.xml”文件。
2、事务管理器定义(chapter9/applicationContext-jdbc.xml):
3、 准备测试环境:
3.1、首先准备测试时使用的SQL:
3.2、初始化Spring容器
3.3、使用高级别方案JdbcTemplate来进行事务管理器测试:
3.4、使用低级别解决方案来进行事务管理器测试:
低级别方案中使用DataSourceUtils获取和释放连接,使用txManager开管理事务,而且面向JDBC编程,比起模板类方式来繁琐和复杂的多,因此不推荐使用该方式。在此就不介绍数据源代理类使用了,需要请参考platformTransactionManagerForLowLevelTest2测试方法。
到此事务管理是不是还很繁琐?必须手工提交或回滚事务,有没有更好的解决方案呢?Spring提供了TransactionTemplate模板类来简化事务管理。
TransactionTemplate模板类用于简化事务管理,事务管理由模板类定义,而具体操作需要通过TransactionCallback回调接口或TransactionCallbackWithoutResult回调接口指定,通过调用模板类的参数类型为TransactionCallback或TransactionCallbackWithoutResult的execute方法来自动享受事务管理。
TransactionTemplate模板类使用的回调接口:
1、接下来演示一下TransactionTemplate模板类如何使用:
这样是不是简单多了,没有事务管理代码,而是由模板类来完成事务管理。
注:对于抛出Exception类型的异常且需要回滚时,需要捕获异常并通过调用status对象的setRollbackOnly()方法告知事务管理器当前事务需要回滚,如下所示:
2、前边已经演示了JDBC事务管理,接下来演示一下JTA分布式事务管理:
jdbcTemplate1.update(INSERT_SQL, "test"):表示向数据库1中的test表中插入数据;
jdbcTemplate2.update(INSERT_SQL, "test"):表示向数据库2中的test表中插入数据,但数据库2没有此表将抛出异常,且JTA分布式事务将回滚;
到此我们已经会使用PlatformTransactionManager和TransactionTemplate进行简单事务处理了,那如何应用到实际项目中去呢?接下来让我们看下如何在实际项目中应用Spring管理事务。
接下来看一下如何将Spring管理事务应用到实际项目中,为简化演示,此处只定义最简单的模型对象和不完整的Dao层接口和Service层接口:
1、 首先定义项目中的模型对象,本示例使用用户模型和用户地址模型:
模型对象一般放在项目中的model包里。
2.1、定义Dao层接口:
2.2、定义Dao层实现:
3.1、定义Service层接口,一般使用“I×××Service”命名:
3.2、定义Service层实现,一般使用“×××ServiceImpl”或“×××Service”命名:
Service实现中需要Spring事务管理的部分应该使用TransactionTemplate模板类来包装执行。
4、定义TransactionTemplateUtils,用于简化获取TransactionTemplate模板类,工具类一般放在util包中:
getDefaultTransactionTemplate用于获取传播行为为PROPAGATION_REQUIRED,隔离级别为ISOLATION_READ_COMMITTED的模板类。
5、数据源配置定义,此处使用第7章的配置文件,即“chapter7/ applicationContext-resources.xml”文件。
6、Dao层配置定义(chapter9/dao/applicationContext-jdbc.xml):
7、Service层配置定义(chapter9/service/applicationContext-service.xml):
8、准备测试需要的表创建语句,在TransactionTest测试类中添加如下静态变量:
9、 测试一下吧:
从Spring容器中获取Service层对象,调用Service层对象持久化对象,大家有没有注意到Spring事务全部在Service层定义,为什么会在Service层定义,而不是Dao层定义呢?这是因为在服务层可能牵扯到业务逻辑,而每个业务逻辑可能调用多个Dao层方法,为保证这些操作的原子性,必须在Service层定义事务。
还有大家有没有注意到如果Service层的事务管理相当令人头疼,而且是侵入式的,有没有办法消除这些冗长的事务管理代码呢?这就需要Spring声明式事务支持,下一节将介绍无侵入式的声明式事务。
可能大家对事务定义中的各种属性有点困惑,如传播行为到底干什么用的?接下来将详细讲解一下事务属性。
事务属性通过TransactionDefinition接口实现定义,主要有事务隔离级别、事务传播行为、事务超时时间、事务是否只读。
Spring提供TransactionDefinition接口默认实现DefaultTransactionDefinition,可以通过该实现类指定这些事务属性。
ISOLATION_DEFAULT:默认隔离级别,即使用底层数据库默认的隔离级别;
ISOLATION_READ_UNCOMMITTED:未提交读;
ISOLATION_READ_COMMITTED:提交读,一般情况下我们使用这个;
ISOLATION_REPEATABLE_READ:可重复读;
ISOLATION_SERIALIZABLE:序列化。
可以使用DefaultTransactionDefinition类的setIsolationLevel(TransactionDefinition. ISOLATION_READ_COMMITTED)来指定隔离级别,其中此处表示隔离级别为提交读,也可以使用或setIsolationLevelName(“ISOLATION_READ_COMMITTED”)方式指定,其中参数就是隔离级别静态变量的名字,但不推荐这种方式。
Required:必须有逻辑事务,否则新建一个事务,使用PROPAGATION_REQUIRED指定,表示如果当前存在一个逻辑事务,则加入该逻辑事务,否则将新建一个逻辑事务,如图9-2和9-3所示;
图9-2 Required传播行为
图9-3 Required传播行为抛出异常情况
在前边示例中就是使用的Required传播行为:
一、在调用userService对象的save方法时,此方法用的是Required传播行为且此时Spring事务管理器发现还没开启逻辑事务,因此Spring管理器觉得开启逻辑事务,
二、在此逻辑事务中调用了addressService对象的save方法,而在save方法中发现同样用的是Required传播行为,因此使用该已经存在的逻辑事务;
三、在返回到addressService对象的save方法,当事务模板类执行完毕,此时提交并关闭事务。
因此userService对象的save方法和addressService的save方法属于同一个物理事务,如果发生回滚,则两者都回滚。
接下来测试一下该传播行为如何执行吧:
一、正确提交测试,如上一节的测试,在此不再演示;
二、回滚测试,修改AddressServiceImpl的save方法片段:
为
二、修改UserServiceImpl的save方法片段:
为
如果该业务方法执行时事务被标记为回滚,则不管在此是否捕获该异常都将发生回滚,因为处于同一逻辑事务。
三、修改测试方法片段:
为如下形式:
Assert断言中countAll方法都返回0,说明事务回滚了,即说明两个业务方法属于同一个物理事务,即使在userService对象的save方法中将异常捕获,由于addressService对象的save方法抛出异常,即事务管理器将自动标识当前事务为需要回滚。
RequiresNew:创建新的逻辑事务,使用PROPAGATION_REQUIRES_NEW指定,表示每次都创建新的逻辑事务(物理事务也是不同的)如图9-4和9-5所示:
图9-4 RequiresNew传播行为
图9-5 RequiresNew传播行为并抛出异常
接下来测试一个该传播行为如何执行吧:
1、将如下获取事务模板方式
替换为如下形式,表示传播行为为RequiresNew:
2、执行如下测试,发现执行结果是正确的:
3、修改UserServiceImpl的save方法片段
为如下形式,表示userServiceImpl类的save方法将发生回滚,而AddressServiceImpl类的方法由于在抛出异常前执行,将成功提交事务到数据库:
4、修改测试方法片段:
为如下形式:
Assert断言中调用userService对象countAll方法返回0,说明该逻辑事务作用域回滚,而调用addressService对象的countAll方法返回1,说明该逻辑事务作用域正确提交。因此这是不正确的行为,因为用户和地址应该是一一对应的,不应该发生这种情况,因此此处正确的传播行为应该是Required。
该传播行为执行流程(正确提交情况):
一、当执行userService对象的save方法时,由于传播行为是RequiresNew,因此创建一个新的逻辑事务(物理事务也是不同的);
二、当执行到addressService对象的save方法时,由于传播行为是RequiresNew,因此首先暂停上一个逻辑事务并创建一个新的逻辑事务(物理事务也是不同的);
三、addressService对象的save方法执行完毕后,提交逻辑事务(并提交物理事务)并重新恢复上一个逻辑事务,继续执行userService对象的save方法内的操作;
四、最后userService对象的save方法执行完毕,提交逻辑事务(并提交物理事务);
五、userService对象的save方法和addressService对象的save方法不属于同一个逻辑事务且也不属于同一个物理事务。
Supports:支持当前事务,使用PROPAGATION_SUPPORTS指定,指如果当前存在逻辑事务,就加入到该逻辑事务,如果当前没有逻辑事务,就以非事务方式执行,如图9-6和9-7所示:
图9-6 Required+Supports传播行为
图9-7 Supports+Supports传播行为
NotSupported:不支持事务,如果当前存在事务则暂停该事务,使用PROPAGATION_NOT_SUPPORTED指定,即以非事务方式执行,如果当前存在逻辑事务,就把当前事务暂停,以非事务方式执行,如图9-8和9-9所示:
图9-8 Required+NotSupported传播行为
图9-9 Supports+NotSupported传播行为
Mandatory:必须有事务,否则抛出异常,使用PROPAGATION_MANDATORY指定,使用当前事务执行,如果当前没有事务,则抛出异常(IllegalTransactionStateException),如图9-10和9-11所示:
图9-10 Required+Mandatory传播行为
图9-11 Supports+Mandatory传播行为
Never:不支持事务,如果当前存在是事务则抛出异常,使用PROPAGATION_NEVER指定,即以非事务方式执行,如果当前存在事务,则抛出异常(IllegalTransactionStateException),如图9-12和9-13所示:
图9-12 Required+Never传播行为
图9-13 Supports+Never传播行为
Nested:嵌套事务支持,使用PROPAGATION_NESTED指定,如果当前存在事务,则在嵌套事务内执行,如果当前不存在事务,则创建一个新的事务,嵌套事务使用数据库中的保存点来实现,即嵌套事务回滚不影响外部事务,但外部事务回滚将导致嵌套事务回滚,如图9-14和9-15所示:
图9-14 Required+Nested传播行为
图9-15 Nested+Nested传播行为
Nested和RequiresNew的区别:
1、 RequiresNew每次都创建新的独立的物理事务,而Nested只有一个物理事务;
2、 Nested嵌套事务回滚或提交不会导致外部事务回滚或提交,但外部事务回滚将导致嵌套事务回滚,而 RequiresNew由于都是全新的事务,所以之间是无关联的;
3、 Nested使用JDBC 3的保存点实现,即如果使用低版本驱动将导致不支持嵌套事务。
使用嵌套事务,必须确保具体事务管理器实现的nestedTransactionAllowed属性为true,否则不支持嵌套事务,如DataSourceTransactionManager默认支持,而HibernateTransactionManager默认不支持,需要我们来开启。
对于事务传播行为我们只演示了Required和RequiresNew,其他传播行为类似,如果对这些事务传播行为不太会使用,请参考chapter9包下的TransactionTest测试类中的testPropagation方法,方法内有详细示例。
使用如setTimeout(100)来设置超时时间,如果事务超时将抛出org.springframework.transaction.TransactionTimedOutException异常并将当前事务标记为应该回滚,即超时后事务被自动回滚;
可以使用具体事务管理器实现的defaultTimeout属性设置默认的事务超时时间,如DataSourceTransactionManager. setDefaultTimeout(10)。
对于JDBC只是简单的将连接设置为只读模式,对于更新将抛出异常;
而对于一些其他ORM框架有一些优化作用,如在Hibernate中,Spring事务管理器将执行“session.setFlushMode(FlushMode.MANUAL)”即指定Hibernate会话在只读事务模式下不用尝试检测和同步持久对象的状态的更新。
如果使用设置具体事务管理的validateExistingTransaction属性为true(默认false),将确保整个事务传播链都是只读或都不是只读,如图9-16是正确的事务只读设置,而图9-17是错误的事务只读设置:
图9-16 正确的事务只读设置
图9-17 错误的事务只读设置
如图10-17,对于错误的事务只读设置将抛出IllegalTransactionStateException异常,并伴随“Participating transaction with definition [……] is not marked as read-only……”信息,表示参与的事务只读属性设置错误。
大家有没有感觉到编程式实现事务管理是不是很繁琐冗长,重复,而且是侵入式的,因此发展到这Spring决定使用配置方式实现事务管理。
在Spring2.x之前为了解决编程式事务管理的各种不好问题,Spring提出使用配置方式实现事务管理,配置方式利用代理机制实现,即使有TransactionProxyFactoryBean类来为目标类代理事务管理。
接下来演示一下具体使用吧:
1、重新定义业务类实现,在业务类中无需显示的事务管理代码:
从以上业务类中可以看出,没有事务管理的代码,即没有侵入式的代码。
2、在chapter9/service/applicationContext-service.xml配置文件中添加如下配置:
2.1、首先添加目标类定义:
2.2、配置TransactionProxyFactoryBean类:
<bean id="transactionProxyParent" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" abstract="true"> <property name="transactionManager" ref="txManager"/> <property name="transactionAttributes"> <props> <prop key="save*"> PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED, timeout_10, -Exception, +NoRollBackException </prop> <prop key="*"> PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED, readOnly </prop> </props> </property> </bean>
注:事务属性的传播行为和隔离级别使用TransactionDefinition静态变量名指定;事务超时使用“timeout_超时时间”指定,事务只读使用“readOnly”指定,需要回滚的异常使用“-异常”指定,不需要回滚的异常使用“+异常”指定,默认只对RuntimeException异常回滚。
需要特别注意“-异常”和“+异常”中“异常”只是真实异常的部分名,内部使用如下方式判断:
因此异常定义时需要特别注意,配置中定义的异常只是真实异常的部分名。
2.3、定义代理Bean:
代理Bean通过集成抽象Bean“transactionProxyParent”,并通过target属性设置目标Bean,在实际使用中应该使用该代理Bean。
3、修改测试方法并测试该配置方式是否好用:
将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testConfigTransaction:
并在testConfigTransaction测试方法内将:
替换为:
4、执行测试,测试正常通过,说明该方式能正常工作,当调用save方法时将匹配到“<prop key="save*">”定义,而countAll将匹配到“<prop key="save*">”定义,底层代理会应用相应定义中的事务属性来创建或关闭事务。
图9-18 代理方式实现事务管理
如图9-18,代理方式实现事务管理只是将硬编码的事务管理代码转移到代理中去由代理实现,在代理中实现事务管理。
注:在代理模式下,默认只有通过代理对象调用的方法才能应用相应的事务属性,而在目标方法内的“自我调用”是不会应用相应的事务属性的,即被调用方法不会应用相应的事务属性,而是使用调用方法的事务属性。
如图9-19所示,在目标对象targetUserService的save方法内调用事务方法“this.otherTransactionMethod()”将不会应用配置的传播行为RequriesNew,开启新事务,而是使用save方法的已开启事务,如果非要这样使用如下方式实现:
1、 修改TransactionProxyFactoryBean配置定义,添加exposeProxy属性为true;
2、 在业务方法内通过代理对象调用相应的事务方放,如 “((IUserService)AopContext.currentProxy()).otherTransactionMethod()”即可应用配置的事务属性。
3、 使用这种方式属于侵入式,不推荐使用,除非必要。
图9-19 代理方式下的自我调用
配置方式也好麻烦啊,每个业务实现都需要配置一个事务代理,发展到这,Spring想出更好的解决方案,Spring2.0及之后版本提出使用新的“<tx:tags/>”方式配置事务,从而无需为每个业务实现配置一个代理。
从上节编程式实现事务管理可以深刻体会到编程式事务的痛苦,即使通过代理配置方式也是不小的工作量。
本节将介绍声明式事务支持,使用该方式后最大的获益是简单,事务管理不再是令人痛苦的,而且此方式属于无侵入式,对业务逻辑实现无影响。
接下来先来看看声明式事务如何实现吧。
1、定义业务逻辑实现,此处使用ConfigUserServiceImpl和ConfigAddressServiceImpl:
2、定义配置文件(chapter9/service/ applicationContext-service-declare.xml):
2.1、XML命名空间定义,定义用于事务支持的tx命名空间和AOP支持的aop命名空间:
2.2、业务实现配置,非常简单,使用以前定义的非侵入式业务实现:
2.3、事务相关配置:
从配置中可以看出,将对cn包及子包下的chapter9. service包及子包下的任何类的任何方法应用“txAdvice”通知指定的事务属性。
3、修改测试方法并测试该配置方式是否好用:
将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testDeclareTransaction:
并在testDeclareTransaction测试方法内将:
替换为:
4、执行测试,测试正常通过,说明该方式能正常工作,当调用save方法时将匹配到事务通知中定义的“<tx:method name="save*">”中指定的事务属性,而调用countAll方法时将匹配到事务通知中定义的“<tx:method name="*">”中指定的事务属性。
声明式事务是如何实现事务管理的呢?还记不记得TransactionProxyFactoryBean实现配置式事务管理,配置式事务管理是通过代理方式实现,而声明式事务管理同样是通过AOP代理方式实现。
声明式事务通过AOP代理方式实现事务管理,利用环绕通知TransactionInterceptor实现事务的开启及关闭,而TransactionProxyFactoryBean内部也是通过该环绕通知实现的,因此可以认为是<tx:tags/>帮你定义了TransactionProxyFactoryBean,从而简化事务管理。
了解了实现方式后,接下来详细学习一下配置吧:
声明式事务管理通过配置<tx:advice/>来定义事务属性,配置方式如下所示:
name:定义与事务属性相关联的方法名,将对匹配的方法应用定义的事务属性,可以使用“*”通配符来匹配一组或所有方法,如“save*”将匹配以save开头的方法,而“*”将匹配所有方法;
propagation:事务传播行为定义,默认为“REQUIRED”,表示Required,其值可以通过TransactionDefinition的静态传播行为变量的“PROPAGATION_”后边部分指定,如“TransactionDefinition.PROPAGATION_REQUIRED”可以使用“REQUIRED”指定;
isolation:事务隔离级别定义;默认为“DEFAULT”,其值可以通过TransactionDefinition的静态隔离级别变量的“ISOLATION_”后边部分指定,如“TransactionDefinition. ISOLATION_DEFAULT”可以使用“DEFAULT”指定:
timeout:事务超时时间设置,单位为秒,默认-1,表示事务超时将依赖于底层事务系统;
read-only:事务只读设置,默认为false,表示不是只读;
rollback-for:需要触发回滚的异常定义,以“,”分割,默认任何RuntimeException 将导致事务回滚,而任何Checked Exception 将不导致事务回滚;异常名字定义和TransactionProxyFactoryBean中含义一样
no-rollback-for:不被触发进行回滚的 Exception(s);以“,”分割;异常名字定义和TransactionProxyFactoryBean中含义一样;
记不记得在配置方式中为了解决“自我调用”而导致的不能设置正确的事务属性问题,使用“((IUserService)AopContext.currentProxy()).otherTransactionMethod()”方式解决,在声明式事务要得到支持需要使用<aop:config expose-proxy="true">来开启。
什么是多事务语义?说白了就是为不同的Bean配置不同的事务属性,因为我们项目中不可能就几个Bean,而可能很多,这可能需要为Bean分组,为不同组的Bean配置不同的事务语义。在Spring中,可以通过配置多切入点和多事务通知并通过不同方式组合使用即可。
1、首先看下声明式事务配置的最佳实践吧:
该声明式事务配置可以应付常见的CRUD接口定义,并实现事务管理,我们只需修改切入点表达式来拦截我们的业务实现从而对其应用事务属性就可以了,如果还有更复杂的事务属性直接添加即可,即
如果我们有一个batchSaveOrUpdate方法需要“REQUIRES_NEW”事务传播行为,则直接添加如下配置即可:
2、接下来看一下多事务语义配置吧,声明式事务最佳实践中已经配置了通用事务属性,因此可以针对需要其他事务属性的业务方法进行特例化配置:
该声明将对切入点匹配的方法所在事务应用“Never”传播行为。
多事务语义配置时,切入点一定不要叠加,否则将应用两次事务属性,造成不必要的错误及麻烦。
对声明式事务管理,Spring提供基于@Transactional注解方式来实现,但需要Java 5+。
注解方式是最简单的事务配置方式,可以直接在Java源代码中声明事务属性,且对于每一个业务类或方法如果需要事务都必须使用此注解。
接下来学习一下注解事务的使用吧:
1、定义业务逻辑实现:
2、定义配置文件(chapter9/service/ applicationContext-service-annotation.xml):
2.1、XML命名空间定义,定义用于事务支持的tx命名空间和AOP支持的aop命名空间:
2.2、业务实现配置,非常简单,使用以前定义的非侵入式业务实现:
<bean id="userService" class="cn.javass.spring.chapter9.service.impl.ConfigUserServiceImpl"> <property name="userDao" ref="userDao"/> <property name="addressService" ref="addressService"/> </bean> <bean id="addressService" class="cn.javass.spring.chapter9.service.impl.ConfigAddressServiceImpl"> <property name="addressDao" ref="addressDao"/> </bean>
2.3、事务相关配置:
使用如上配置已支持声明式事务。
3、修改测试方法并测试该配置方式是否好用:
将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testAnntationTransactionTest:
将测试代码片段:
替换为:
将测试代码段
替换为:
4、执行测试,测试正常通过,说明该方式能正常工作,因为在AnnotationAddressServiceImpl类的save方法中抛出异常,因此事务需要回滚,所以两个countAll操作都返回0。
Spring提供的<tx:annotation-driven/>用于开启对注解事务管理的支持,从而能识别Bean类上的@Transactional注解元数据,其具有以下属性:
Spring使用@Transaction来指定事务属性,可以在接口、类或方法上指定,如果类和方法上都指定了@Transaction,则方法上的事务属性被优先使用,具体属性如下:
Spring提供的@Transaction注解事务管理内部同样利用环绕通知TransactionInterceptor实现事务的开启及关闭。
使用@Transactional注解事务管理需要特别注意以下几点:
Spring声明式事务实现其实就是Spring AOP+线程绑定实现,利用AOP实现开启和关闭事务,利用线程绑定(ThreadLocal)实现跨越多个方法实现事务传播。
由于我们不可能只使用一个事务通知,可能还有其他类型事务通知,而且如果这些通知中需要事务支持怎么办?这就牵扯到通知执行顺序的问题上了,因此如果可能与其他AOP通知协作的话,而且这些通知中需要使用声明式事务管理支持,事务通知应该具有最高优先级。
编程式事务时不推荐的,即使有很少事务操作,Spring发展到现在,没有理由使用编程式事务,只有在为了深入理解Spring事务管理才需要学习编程式事务使用。
推荐使用声明式事务,而且强烈推荐使用<tx:tags>方式的声明式事务,因为其是无侵入代码的,可以配置模板化的事务属性并运用到多个项目中。
而@Transaction注解事务,可以使用,不过作者更倾向于使用<tx:tags>声明式事务。
能保证项目正常工作的事务配置就是最好的。
所谓混合事务管理就是混合多种数据访问技术使用,如混合使用Spring JDBC + Hibernate,接下来让我们学习一下常见混合事务管理:
1、 Hibernate + Spring JDBC/iBATIS:使用HibernateTransactionManager即可支持;
2、 JPA + Spring JDBC/iBATIS:使用JpaTransactionManager即可支持;
3、 JDO + Spring JDBC/iBATIS:使用JtaTransactionManager即可支持;
混合事务管理最大问题在于如果我们使用第三方ORM框架,如Hibernate,会遇到一级及二级缓存问题,尤其是二级缓存可能造成如使用Spring JDBC和Hibernate查询出来的数据不一致等。
因此不建议使用这种混合使用和混合事务管理。
标签:des style class blog code java
原文地址:http://www.cnblogs.com/duanxz/p/3788190.html