也許你會(huì)奇怪,為什么接口只提供了獲取屬性的方法,而沒有提供相關(guān)設(shè)置屬性的方法。其實(shí)道理很簡(jiǎn)單,事務(wù)屬性的設(shè)置完全是程序員控制的,因此程序員可以自定義任何設(shè)置屬性的方法,而且保存屬性的字段也沒有任何要求。唯一的要求的是,Spring 進(jìn)行事務(wù)操作的時(shí)候,通過調(diào)用以上接口提供的方法必須能夠返回事務(wù)相關(guān)的屬性取值。
事務(wù)隔離級(jí)別
隔離級(jí)別是指若干個(gè)并發(fā)的事務(wù)之間的隔離程度。TransactionDefinition 接口中定義了五個(gè)表示隔離級(jí)別的常量:
TransactionDefinition.ISOLATION_DEFAULT:這是默認(rèn)值,表示使用底層數(shù)據(jù)庫的默認(rèn)隔離級(jí)別。對(duì)大部分?jǐn)?shù)據(jù)庫而言,通常這值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
TransactionDefinition.ISOLATION_READ_UNCOMMITTED:該隔離級(jí)別表示一個(gè)事務(wù)可以讀取另一個(gè)事務(wù)修改但還沒有提交的數(shù)據(jù)。該級(jí)別不能防止臟讀和不可重復(fù)讀,因此很少使用該隔離級(jí)別。
TransactionDefinition.ISOLATION_READ_COMMITTED:該隔離級(jí)別表示一個(gè)事務(wù)只能讀取另一個(gè)事務(wù)已經(jīng)提交的數(shù)據(jù)。該級(jí)別可以防止臟讀,這也是大多數(shù)情況下的推薦值。
TransactionDefinition.ISOLATION_REPEATABLE_READ:該隔離級(jí)別表示一個(gè)事務(wù)在整個(gè)過程中可以多次重復(fù)執(zhí)行某個(gè)查詢,并且每次返回的記錄都相同。即使在多次查詢之間有新增的數(shù)據(jù)滿足該查詢,這些新增的記錄也會(huì)被忽略。該級(jí)別可以防止臟讀和不可重復(fù)讀。
TransactionDefinition.ISOLATION_SERIALIZABLE:所有的事務(wù)依次逐個(gè)執(zhí)行,這樣事務(wù)之間就完全不可能產(chǎn)生干擾,也就是說,該級(jí)別可以防止臟讀、不可重復(fù)讀以及幻讀。但是這將嚴(yán)重影響程序的性能。通常情況下也不會(huì)用到該級(jí)別。
事務(wù)傳播行為
所謂事務(wù)的傳播行為是指,如果在開始當(dāng)前事務(wù)之前,一個(gè)事務(wù)上下文已經(jīng)存在,此時(shí)有若干選項(xiàng)可以指定一個(gè)事務(wù)性方法的執(zhí)行行為。在TransactionDefinition定義中包括了如下幾個(gè)表示傳播行為的常量:
TransactionDefinition.PROPAGATION_REQUIRED:如果當(dāng)前存在事務(wù),則加入該事務(wù);如果當(dāng)前沒有事務(wù),則創(chuàng)建一個(gè)新的事務(wù)。
TransactionDefinition.PROPAGATION_REQUIRES_NEW:創(chuàng)建一個(gè)新的事務(wù),如果當(dāng)前存在事務(wù),則把當(dāng)前事務(wù)掛起。
TransactionDefinition.PROPAGATION_SUPPORTS:如果當(dāng)前存在事務(wù),則加入該事務(wù);如果當(dāng)前沒有事務(wù),則以非事務(wù)的方式繼續(xù)運(yùn)行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事務(wù)方式運(yùn)行,如果當(dāng)前存在事務(wù),則把當(dāng)前事務(wù)掛起。
TransactionDefinition.PROPAGATION_NEVER:以非事務(wù)方式運(yùn)行,如果當(dāng)前存在事務(wù),則拋出異常。
TransactionDefinition.PROPAGATION_MANDATORY:如果當(dāng)前存在事務(wù),則加入該事務(wù);如果當(dāng)前沒有事務(wù),則拋出異常。
TransactionDefinition.PROPAGATION_NESTED:如果當(dāng)前存在事務(wù),則創(chuàng)建一個(gè)事務(wù)作為當(dāng)前事務(wù)的嵌套事務(wù)來運(yùn)行;如果當(dāng)前沒有事務(wù),則該取值等價(jià)于TransactionDefinition.PROPAGATION_REQUIRED。
這里需要指出的是,前面的六種事務(wù)傳播行為是 Spring 從 EJB 中引入的,他們共享相同的概念。而 PROPAGATION_NESTED是 Spring 所特有的。以 PROPAGATION_NESTED 啟動(dòng)的事務(wù)內(nèi)嵌于外部事務(wù)中(如果存在外部事務(wù)的話),此時(shí),內(nèi)嵌事務(wù)并不是一個(gè)**的事務(wù),它依賴于外部事務(wù)的存在,只有通過外部的事務(wù)提交,才能引起內(nèi)部事務(wù)的提交,嵌套的子事務(wù)不能單獨(dú)提交。如果熟悉 JDBC 中的保存點(diǎn)(SavePoint)的概念,那嵌套事務(wù)就很容易理解了,其實(shí)嵌套的子事務(wù)就是保存點(diǎn)的一個(gè)應(yīng)用,一個(gè)事務(wù)中可以包括多個(gè)保存點(diǎn),每一個(gè)嵌套子事務(wù)。另外,外部事務(wù)的回滾也會(huì)導(dǎo)致嵌套子事務(wù)的回滾。
事務(wù)超時(shí)
所謂事務(wù)超時(shí),就是指一個(gè)事務(wù)所允許執(zhí)行的最長(zhǎng)時(shí)間,如果超過該時(shí)間限制但事務(wù)還沒有完成,則自動(dòng)回滾事務(wù)。在 TransactionDefinition 中以 int 的值來表示超時(shí)時(shí)間,其單位是秒。
事務(wù)的只讀屬性
事務(wù)的只讀屬性是指,對(duì)事務(wù)性資源進(jìn)行只讀操作或者是讀寫操作。所謂事務(wù)性資源就是指那些被事務(wù)管理的資源,比如數(shù)據(jù)源、 JMS 資源,以及自定義的事務(wù)性資源等等。如果確定只對(duì)事務(wù)性資源進(jìn)行只讀操作,那么我們可以將事務(wù)標(biāo)志為只讀的,以提高事務(wù)處理的性能。在 TransactionDefinition 中以 boolean 類型來表示該事務(wù)是否只讀。
事務(wù)的回滾規(guī)則
通常情況下,如果在事務(wù)中拋出了未檢查異常(繼承自 RuntimeException 的異常),則默認(rèn)將回滾事務(wù)。如果沒有拋出任何異常,或者拋出了已檢查異常,則仍然提交事務(wù)。這通常也是大多數(shù)開發(fā)者希望的處理方式,也是 EJB 中的默認(rèn)處理方式。但是,我們可以根據(jù)需要人為控制事務(wù)在拋出某些未檢查異常時(shí)任然提交事務(wù),或者在拋出某些已檢查異常時(shí)回滾事務(wù)。
Spring 事務(wù)管理 API 分析
Spring 框架中,涉及到事務(wù)管理的 API 大約有100個(gè)左右,其中最重要的有三個(gè):TransactionDefinition、PlatformTransactionManager、 TransactionStatus。所謂事務(wù)管理,其實(shí)就是“按照給定的事務(wù)規(guī)則來執(zhí)行提交或者回滾操作”。“給定的事務(wù)規(guī)則”就是用 TransactionDefinition 表示的,“按照……來執(zhí)行提交或者回滾操作”便是用 PlatformTransactionManager 來表示,而 TransactionStatus 用于表示一個(gè)運(yùn)行著的事務(wù)的狀態(tài)。打一個(gè)不恰當(dāng)?shù)谋扔鳎琓ransactionDefinition 與 TransactionStatus 的關(guān)系就像程序和進(jìn)程的關(guān)系。
TransactionDef...
該接口在前面已經(jīng)介紹過,它用于定義一個(gè)事務(wù)。它包含了事務(wù)的靜態(tài)屬性,比如:事務(wù)傳播行為、超時(shí)時(shí)間等等。Spring 為我們提供了一個(gè)默認(rèn)的實(shí)現(xiàn)類:DefaultTransactionDefinition,該類適用于大多數(shù)情況。如果該類不能滿足需求,可以通過實(shí)現(xiàn) TransactionDefinition 接口來實(shí)現(xiàn)自己的事務(wù)定義。
PlatformTrans...
PlatformTransactionManager 用于執(zhí)行具體的事務(wù)操作。接口定義如清單2所示:
清單2. PlatformTransactionManager 接口中定義的主要方法
Public interface PlatformTransactionManager{
TransactionStatus getTransaction(TransactionDefinition definition)
throws TransactionException;
void commit(TransactionStatus status)throws TransactionException;
void rollback(TransactionStatus status)throws TransactionException;
}
根據(jù)底層所使用的不同的持久化 API 或框架,PlatformTransactionManager 的主要實(shí)現(xiàn)類大致如下:
DataSourceTransactionManager:適用于使用JDBC和iBatis進(jìn)行數(shù)據(jù)持久化操作的情況。
HibernateTransactionManager:適用于使用Hibernate進(jìn)行數(shù)據(jù)持久化操作的情況。
JpaTransactionManager:適用于使用JPA進(jìn)行數(shù)據(jù)持久化操作的情況。
另外還有JtaTransactionManager 、JdoTransactionManager、JmsTransactionManager等等。
如果我們使用JTA進(jìn)行事務(wù)管理,我們可以通過 JNDI 和 Spring 的 JtaTransactionManager 來獲取一個(gè)容器管理的 DataSource。JtaTransactionManager 不需要知道 DataSource 和其他特定的資源,因?yàn)樗鼘⑹褂萌萜魈峁┑娜质聞?wù)管理。而對(duì)于其他事務(wù)管理器,比如DataSourceTransactionManager,在定義時(shí)需要提供底層的數(shù)據(jù)源作為其屬性,也就是 DataSource。與 HibernateTransactionManager 對(duì)應(yīng)的是 SessionFactory,與 JpaTransactionManager 對(duì)應(yīng)的是 EntityManagerFactory 等等。
TransactionStatus
PlatformTransactionManager.getTransaction(…) 方法返回一個(gè) TransactionStatus 對(duì)象。返回的TransactionStatus 對(duì)象可能代表一個(gè)新的或已經(jīng)存在的事務(wù)(如果在當(dāng)前調(diào)用堆棧有一個(gè)符合條件的事務(wù))。TransactionStatus 接口提供了一個(gè)簡(jiǎn)單的控制事務(wù)執(zhí)行和查詢事務(wù)狀態(tài)的方法。該接口定義如清單3所示:
清單3. TransactionStatus 接口中定義的主要方法
public interface TransactionStatus{
boolean isNewTransaction();
void setRollbackOnly();
boolean isRollbackOnly();
}
Spring 的編程式事務(wù)管理概述
在 Spring 出現(xiàn)以前,編程式事務(wù)管理對(duì)基于 POJO 的應(yīng)用來說是唯一選擇。用過 Hibernate 的人都知道,我們需要在代碼中顯式調(diào)用beginTransaction()、commit()、rollback()等事務(wù)管理相關(guān)的方法,這就是編程式事務(wù)管理。通過 Spring 提供的事務(wù)管理 API,我們可以在代碼中靈活控制事務(wù)的執(zhí)行。在底層,Spring 仍然將事務(wù)操作委托給底層的持久化框架來執(zhí)行。
基于底層 API 的編程式事務(wù)管理
根據(jù)PlatformTransactionManager、TransactionDefinition 和 TransactionStatus 三個(gè)核心接口,我們完全可以通過編程的方式來進(jìn)行事務(wù)管理。示例代碼如清單4所示:
清單4. 基于底層 API 的事務(wù)管理示例代碼
public class BankServiceImpl implements BankService {
private BankDao bankDao;
private TransactionDefinition txDefinition;
private PlatformTransactionManager txManager;
......
public boolean transfer(Long fromId, Long toId, double amount) {
TransactionStatus txStatus = txManager.getTransaction(txDefinition);
boolean result = false;
try {
result = bankDao.transfer(fromId, toId, amount);
txManager.commit(txStatus);
} catch (Exception e) {
result = false;
txManager.rollback(txStatus);
System.out.println("Transfer Error!");
}
return result;
}
}
相應(yīng)的配置文件如清單5所示:
清單5. 基于底層API的事務(wù)管理示例配置文件
<bean id="bankService" class="footmark.spring.core.tx.programmatic.origin.BankServiceImpl">
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
<property name="bankDao" ref="bankDao"/>
<property name="txManager" ref="transactionManager"/>
<property name="txDefinition">
<bean class="org.springframework.transaction.support.DefaultTransactionDefinition">
<property name="propagationBehaviorName" value="PROPAGATION_REQUIRED"/>
</bean>
</property>
</bean>
如上所示,我們?cè)陬愔性黾恿藘蓚€(gè)屬性:一個(gè)是 TransactionDefinition 類型的屬性,它用于定義一個(gè)事務(wù);另一個(gè)是 PlatformTransactionManager 類型的屬性,用于執(zhí)行事務(wù)管理操作。
如果方法需要實(shí)施事務(wù)管理,我們首先需要在方法開始執(zhí)行前啟動(dòng)一個(gè)事務(wù),調(diào)用PlatformTransactionManager.getTransaction(...) 方法便可啟動(dòng)一個(gè)事務(wù)。創(chuàng)建并啟動(dòng)了事務(wù)之后,便可以開始編寫業(yè)務(wù)邏輯代碼,然后在適當(dāng)?shù)牡胤綀?zhí)行事務(wù)的提交或者回滾。
基于 TransactionTemplate 的編程式事務(wù)管理
通過前面的示例可以發(fā)現(xiàn),這種事務(wù)管理方式很容易理解,但令人頭疼的是,事務(wù)管理的代碼散落在業(yè)務(wù)邏輯代碼中,破壞了原有代碼的條理性,并且每一個(gè)業(yè)務(wù)方法都包含了類似的啟動(dòng)事務(wù)、提交/回滾事務(wù)的樣板代碼。幸好,Spring 也意識(shí)到了這些,并提供了簡(jiǎn)化的方法,這就是 Spring 在數(shù)據(jù)訪問層非常常見的模板回調(diào)模式。如清單6所示:
清單6. 基于 TransactionTemplate 的事務(wù)管理示例代碼
public class BankServiceImpl implements BankService {
private BankDao bankDao;
private TransactionTemplate transactionTemplate;
......
public boolean transfer(final Long fromId, final Long toId, final double amount) {
return (Boolean) transactionTemplate.execute(new TransactionCallback(){
public Object doInTransaction(TransactionStatus status) {
Object result;
try {
result = bankDao.transfer(fromId, toId, amount);
} catch (Exception e) {
status.setRollbackOnly();
result = false;
System.out.println("Transfer Error!");
}
return result;
}
});
}
}
相應(yīng)的XML配置如下:
清單 7. 基于 TransactionTemplate 的事務(wù)管理示例配置文件
<bean id="bankService"
class="footmark.spring.core.tx.programmatic.template.BankServiceImpl">
<property name="bankDao" ref="bankDao"/>
<property name="transactionTemplate" ref="transactionTemplate"/>
</bean>
TransactionTemplate 的 execute() 方法有一個(gè) TransactionCallback 類型的參數(shù),該接口中定義了一個(gè) doInTransaction() 方法,通常我們以匿名內(nèi)部類的方式實(shí)現(xiàn) TransactionCallback 接口,并在其 doInTransaction() 方法中書寫業(yè)務(wù)邏輯代碼。這里可以使用默認(rèn)的事務(wù)提交和回滾規(guī)則,這樣在業(yè)務(wù)代碼中就不需要顯式調(diào)用任何事務(wù)管理的 API。doInTransaction() 方法有一個(gè)TransactionStatus 類型的參數(shù),我們可以在方法的任何位置調(diào)用該參數(shù)的 setRollbackOnly() 方法將事務(wù)標(biāo)識(shí)為回滾的,以執(zhí)行事務(wù)回滾。
根據(jù)默認(rèn)規(guī)則,如果在執(zhí)行回調(diào)方法的過程中拋出了未檢查異常,或者顯式調(diào)用了TransacationStatus.setRollbackOnly() 方法,則回滾事務(wù);如果事務(wù)執(zhí)行完成或者拋出了 checked 類型的異常,則提交事務(wù)。
TransactionCallback 接口有一個(gè)子接口 TransactionCallbackWithoutResult,該接口中定義了一個(gè) doInTransactionWithoutResult() 方法,TransactionCallbackWithoutResult 接口主要用于事務(wù)過程中不需要返回值的情況。當(dāng)然,對(duì)于不需要返回值的情況,我們?nèi)匀豢梢允褂?TransactionCallback 接口,并在方法中返回任意值即可。
Spring 的聲明式事務(wù)管理概述
Spring 的聲明式事務(wù)管理在底層是建立在 AOP 的基礎(chǔ)之上的。其本質(zhì)是對(duì)方法前后進(jìn)行攔截,然后在目標(biāo)方法開始之前創(chuàng)建或者加入一個(gè)事務(wù),在執(zhí)行完目標(biāo)方法之后根據(jù)執(zhí)行情況提交或者回滾事務(wù)。
聲明式事務(wù)最大的優(yōu)點(diǎn)就是不需要通過編程的方式管理事務(wù),這樣就不需要在業(yè)務(wù)邏輯代碼中摻雜事務(wù)管理的代碼,只需在配置文件中做相關(guān)的事務(wù)規(guī)則聲明(或通過等價(jià)的基于標(biāo)注的方式),便可以將事務(wù)規(guī)則應(yīng)用到業(yè)務(wù)邏輯中。因?yàn)槭聞?wù)管理本身就是一個(gè)典型的橫切邏輯,正是 AOP 的用武之地。Spring 開發(fā)團(tuán)隊(duì)也意識(shí)到了這一點(diǎn),為聲明式事務(wù)提供了簡(jiǎn)單而強(qiáng)大的支持。
聲明式事務(wù)管理曾經(jīng)是 EJB 引以為傲的一個(gè)亮點(diǎn),如今 Spring 讓 POJO 在事務(wù)管理方面也擁有了和 EJB 一樣的待遇,讓開發(fā)人員在 EJB 容器之外也用上了強(qiáng)大的聲明式事務(wù)管理功能,這主要得益于 Spring 依賴注入容器和 Spring AOP 的支持。依賴注入容器為聲明式事務(wù)管理提供了基礎(chǔ)設(shè)施,使得 Bean 對(duì)于 Spring 框架而言是可管理的;而 Spring AOP 則是聲明式事務(wù)管理的直接實(shí)現(xiàn)者,這一點(diǎn)通過清單8可以看出來。
通常情況下,筆者強(qiáng)烈建議在開發(fā)中使用聲明式事務(wù),不僅因?yàn)槠浜?jiǎn)單,更主要是因?yàn)檫@樣使得純業(yè)務(wù)代碼不被污染,極大方便后期的代碼維護(hù)。
和編程式事務(wù)相比,聲明式事務(wù)唯一不足地方是,后者的最細(xì)粒度只能作用到方法級(jí)別,無法做到像編程式事務(wù)那樣可以作用到代碼塊級(jí)別。但是即便有這樣的需求,也存在很多變通的方法,比如,可以將需要進(jìn)行事務(wù)管理的代碼塊**為方法等等。
下面就來看看 Spring 為我們提供的聲明式事務(wù)管理功能。
基于 TransactionInter... 的聲明式事務(wù)管理
最初,Spring 提供了 TransactionInterceptor 類來實(shí)施聲明式事務(wù)管理功能。先看清單8的配置文件:
清單 8. 基于 TransactionInterceptor 的事務(wù)管理示例配置文件
<beans...>
......
<bean id="transactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager" ref="transactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="transfer">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<bean id="bankServiceTarget"
class="footmark.spring.core.tx.declare.origin.BankServiceImpl">
<property name="bankDao" ref="bankDao"/>
</bean>
<bean id="bankService"
class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="target" ref="bankServiceTarget"/>
<property name="interceptorNames">
<list>
<idref bean="transactionInterceptor"/>
</list>
</property>
</bean>
......
</beans>