在spring中使用聲明型事務
spring使用aop機制管理jdbc的連接和事務。它使用TransactionInterceptor類，Spring事務支持中的核心接口是
org.springframework.transaction.PlatformTransactionManager。爲了實際執行事務，Spring所有的事務劃分功能都通過傳遞適當的TransactionDefinition實例，委託給 PlatformTransactionManager。
儘管PlatformTransactionManager接口可以直接使用，應用程序通常配置具體的事務管理器並使用聲明性事務來劃分事務。
Spring具有多種PlatformTransactionManager實現，它們分爲兩類：
局部事務策略即針對單個資源執行事務（主要是針對單個的數據庫）。實現有 org.springframework.jdbc.datasource.DataSourceTransactionManager。它用於jdbc數據源的配置，調用TransactionInterceptor開是一個事務,
從DataSource得到一個connection並確保auto-commit設爲disabled。他用JdbcTemplate在一個線程內綁定一個JDBC connection，TransactionInterceptor負責提交事務，
DataSourceTransactionManager 調用Connection.commit()關閉connection,並解除綁定（potentially allowing for one thread connection per data source）。
例如
<bean id="DataSource"
class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>oracle.jdbc.driver.OracleDriver</value>
</property>
<property name="url">
<value>jdbc:oracle:thin:@localhost:1521:hua2</value>
</property>
<property name="username">
<value>user</value></property>
<property name="password">
<value>gotpassword</value>
</property>
</bean>
</beans>
<bean id="DataSourceTransactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="DataSource" />
</bean>
<bean id="tatanTransactionScriptsProxyCreator"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<idref bean="tatanTransactionScripts" />
</list>
</property>
<property name="interceptorNames">
<list>
<idref bean="DataSourceTransactionInterceptor" />
</list>
</property>
</bean>
<bean id="DataSourceTransactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager"
ref="DataSourceTransactionManager" />
<property name="transactionAttributeSource">
<value>
com.tatan.tatanTransactionScriptsImpl.*=PROPAGATION_REQUIRED
</value>
</property>
</bean>
transactionAttributesSource 屬性指定每個方法的transaction attribute，PROPAGATION_REQUIRED說明在一個事務內這個方法被執行。
和EJB一樣，默認的情況下，spring只有當unchecked exception被拋出時，才rollback事務，也可以自己加入checked exception。
tatanTransactionScripts被TransactionInterceptor封裝，在一個事物內執行類的每一個方法。
更爲簡單的配置

    <bean id="UserManagerTran"
            class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
            <property name="transactionManager">
                <ref bean="transactionManager"/></property>
            <property name="target"><ref bean="UserManager"/></property>
            <property name="transactionAttributes">
                <props>
                    <prop key="insert*">
                        PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED</prop>
                    <prop key="tran*">
                        PROPAGATION_REQUIRED, ISOLATION_SERIALIZABLE</prop>
                    <prop key="deposit*">
                        PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED</prop>
                </props>
            </property>
        </bean>
         <bean id="transactionManager"
           class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
           <property name="dataSource"><ref bean="dataSource"/></property>
       </bean>

（The TransactionProxyFactoryBean is a ProxyFactoryBean where every bean is adviced with a TransactionInterceptor. And the TransactionInterceptor is a piece of advice.
So you can use a seperate TransactionInterceptor and ProxyFactoryBean. But if you are lazy/smart, you can use the TransactionProxyFactoryBean that does the same thing (only less configuration needed)）
對於特定的方法或方法命名模式，代理的具體事務行爲由事務屬性驅動，如下面的例子所示：
<prop key="insert*">
ROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED
</prop>
key屬性確定代理應該給哪個方法增加事務行爲。這樣的屬性最重要的部份是傳播行爲。有以下選項可供使用：
PROPAGATION_REQUIRED--支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇。
PROPAGATION_SUPPORTS--支持當前事務，如果當前沒有事務，就以非事務方式執行。
PROPAGATION_MANDATORY--支持當前事務，如果當前沒有事務，就拋出異常。
PROPAGATION_REQUIRES_NEW--新建事務，如果當前存在事務，把當前事務掛起。
PROPAGATION_NOT_SUPPORTED--以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
PROPAGATION_NEVER--以非事務方式執行，如果當前存在事務，則拋出異常。
PROPAGATION_NESTED--如果當前存在事務，則在嵌套事務內執行。如果當前沒有事務，則進行與PROPAGATION_REQUIRED類似的操作。
前六個策略類似於EJB CMT，第七個（PROPAGATION_NESTED）是Spring所提供的一個特殊變量。
它要求事務管理器或者使用JDBC 3.0 Savepoint API提供嵌套事務行爲（如Spring的DataSourceTransactionManager）。
事務屬性中的readOnly標誌表示對應的事務應該被最優化爲只讀事務。這是一個最優化提示。在一些情況下，一些事務策略能夠起到顯著的最優化效果，例如在使用Object/Relational映射工具（如：Hibernate或TopLink）時避免dirty checking（試圖“刷新”）。
在事務屬性中還有定義“timeout”值的選項，指定事務超時爲幾秒。在JTA中，這將被簡單地傳遞到J2EE服務器的事務協調程序，並據此得到相應的解釋。

全局事務管理即執行有可能跨越多個資源的全局事務。主要對應的Spring類是org.springframework.transaction.jta.JtaTransactionManager，它委託給遵循JTA規範的J2EE服務器，也有例外。
spring支持JTA，只需要一個標準的JtaTransactionManager定義，數據庫必須支持XA protocol，或者J2EE服務器提供支持XA規範的DataSource。
默認的Spring JtaTransactionManager設置將從標準的JNDI位置獲取JTA的 javax.transaction.UserTransaction對象，該JNDI位置由J2EE指定：java:comp/UserTransaction。對於大多數標準J2EE環境下的用例來說，它工作良好。
但是，默認的 JtaTransactionManager不能執行事務掛起操作(即它不支持PROPAGATION_REQUIRES_NEW和 PROPAGATION_NOT_SUPPORTED)。原因是標準的JTA UserTransaction接口不支持掛起或恢復事務的操作；它只支持開始和完成新事務的操作。
爲執行事務掛起操作，還需要提供javax.transaction.TransactionManager實例，按照JTA的規定，它提供標準的掛起和恢復方法。遺憾的是，J2EE沒有爲JTA TransactionManager定義標準的JNDI位置！
因此，必須使用特定於供應商的(vendor-specific)查尋機制。J2EE沒有考慮把JTA TransactionManager接口作爲它的公開API的一部分。JTA規範規定的TransactionManager接口原本是打算用於容器集成的。
但是爲JTA TransactionManager定義標準的JNDI位置還是有重大意義的，尤其是對於輕量級容器（如Spring）；然後，便可以以同樣的方式來定位任意的J2EE服務器的JTA TransactionManager。
結合jboss JTA的Spring事務劃分
oracle-ds.xml
<?xml version="1.0" encoding="UTF-8"?>

<datasources>
<xa-datasource>
  <jndi-name>XASpringDS</jndi-name>
  <track-connection-by-tx/>
  <isSameRM-override-value>false</isSameRM-override-value>
  <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
  <xa-datasource-property name="URL">jdbc:oracle:oci8:@orcl</xa-datasource-property>
  <xa-datasource-property name="User">SCOTT</xa-datasource-property>
  <xa-datasource-property name="Password">tiger</xa-datasource-property>
  <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
  <no-tx-separate-pools/>
</xa-datasource>
<mbean
  code="org.jboss.resource.adapter.jdbc.xa.oracle.OracleXAExceptionFormatter"
  name="jboss.jca:service=OracleXAExceptionFormatter">
  <depends optional-attribute-name="TransactionManagerService">
   jboss:service=TransactionManager</depends>
</mbean>
</datasources>
spring配置


<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
  <property name="jndiName"><value>java:/XASpringDS</value></property>
</bean>

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>

Spring有效地將DAO實現從實際的運行時環境中分離出來，允許在J2EE容器之外輕鬆地測試或重用用。
Spring提供了多種事務策略，比如JtaTransactionManager和JDBC DataSourceTransactionManager，
前者委託給J2EE服務器的事務協調程序，後者則針對單個JDBC DataSource（即單個的目標數據庫）執行事務。
通過對後端配置進行簡單的更改，就能夠輕鬆地調整事務策略適應另一個環境。

http://blogger.org.cn/blog/more.asp?name=hongrui&id=11162

Spring事務傳播機制解惑

概述

當我們調用一個基於Spring的Service接口方法（如UserService#addUser()）時，它將運行於Spring管理的事務環境中，Service接口方法可能會在內部調用其它的Service接口方法以共同完成一個完整的業務操作，因此就會產生服務接口方法嵌套調用的情況，Spring通過事務傳播行爲控制當前的事務如何傳播到被嵌套調用的目標服務接口方法中。

事務傳播是Spring進行事務管理的重要概念，其重要性怎麼強調都不爲過。但是事務傳播行爲也是被誤解最多的地方，在本文裏，我們將詳細分析不同事務傳播行爲的表現形式，掌握它們之間的區別。

事務傳播行爲種類

Spring在TransactionDefinition接口中規定了7種類型的事務傳播行爲，它們規定了事務方法和事務方法發生嵌套調用時事務如何進行傳播：

表 1事務傳播行爲類型

事務傳播行爲類型	說明
PROPAGATION_REQUIRED	如果當前沒有事務，就新建一個事務，如果已經存在一個事務中，加入到這個事務中。這是最常見的選擇。
PROPAGATION_SUPPORTS	支持當前事務，如果當前沒有事務，就以非事務方式執行。
PROPAGATION_MANDATORY	使用當前的事務，如果當前沒有事務，就拋出異常。
PROPAGATION_REQUIRES_NEW	新建事務，如果當前存在事務，把當前事務掛起。
PROPAGATION_NOT_SUPPORTED	以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
PROPAGATION_NEVER	以非事務方式執行，如果當前存在事務，則拋出異常。
PROPAGATION_NESTED	如果當前存在事務，則在嵌套事務內執行。如果當前沒有事務，則執行與PROPAGATION_REQUIRED類似的操作。

當使用PROPAGATION_NESTED時，底層的數據源必須基於JDBC 3.0，並且實現者需要支持保存點事務機制。

幾種容易引起誤解的組合事務傳播行爲

當服務接口方法分別使用表1中不同的事務傳播行爲，且這些接口方法又發生相互調用的情況下，大部分組合都是一目瞭然，容易理解的。但是，也存在一些容易引起誤解的組合事務傳播方式。

下面，我們通過兩個具體的服務接口的組合調用行爲來破解這一難點。這兩個服務接口分別是UserService和 ForumService，UserSerice有一個addCredits()方法，ForumSerivce#addTopic()方法調用了 UserSerice#addCredits()方法，發生關聯性服務方法的調用：

public class ForumService {

private UserService userService;

public void addTopic() {①調用其它服務接口的方法

//add Topic…

userService.addCredits() ;②被關聯調用的業務方法

}

嵌套調用的事務方法

對Spring事務傳播行爲最常見的一個誤解是：當服務接口方法發生嵌套調用時，被調用的服務方法只能聲明爲 PROPAGATION_NESTED。這種觀點犯了望文生義的錯誤，誤認爲PROPAGATION_NESTED是專爲方法嵌套準備的。這種誤解遺害不淺，執有這種誤解的開發者錯誤地認爲：應儘量不讓Service類的業務方法發生相互的調用，Service類只能調用DAO層的DAO類，以避免產生嵌套事務。

其實，這種顧慮是完全沒有必要的，PROPAGATION_REQUIRED已經清楚地告訴我們：事務的方法會足夠“聰明”地判斷上下文是否已經存在一個事務中，如果已經存在，就加入到這個事務中，否則創建一個新的事務。

依照上面的例子，假設我們將ForumService#addTopic()和UserSerice#addCredits()方法的事務傳播行爲都設置爲PROPAGATION_REQUIRED，這兩個方法將運行於同一個事務中。

爲了清楚地說明這點，可以將Log4J的日誌設置爲DEBUG級別，以觀察Spring事務管理器內部的運行情況。下面將兩個業務方法都設置爲PROPAGATION_REQUIRED，Spring所輸出的日誌信息如下：

Using transaction object

[org.springframework.jdbc.datasource.DataSourceTransactionManager$DataSourceTransactionObject@e3849c]

①爲 ForumService#addTopic() 新建一個事務

Creating new transaction with name [com.baobaotao.service.ForumService.addTopic]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT

Acquired Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5] for JDBC transaction

Switching JDBC Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5] to manual commit

Bound value [org.springframework.jdbc.datasource.ConnectionHolder@ee1ede] for key [org.apache.commons.dbcp.BasicDataSource@4204] to thread [main]

Initializing transaction synchronization

Getting transaction for [com.baobaotao.service.ForumService.addTopic]

Retrieved value [org.springframework.jdbc.datasource.ConnectionHolder@ee1ede] for key [org.apache.commons.dbcp.BasicDataSource@4204] bound to thread [main]

Using transaction object [org.springframework.jdbc.datasource.DataSourceTransactionManager$DataSourceTransactionObject@8b8a47]

② UserService#addCredits() 簡單地加入到已存在的事務中（即①處創建的事務）

Participating in existing transaction

Getting transaction for [com.baobaotao.service.UserService.addCredits]

Completing transaction for [com.baobaotao.service.UserService.addCredits]

Completing transaction for [com.baobaotao.service.ForumService.addTopic]

Triggering beforeCommit synchronization

Triggering beforeCompletion synchronization

Initiating transaction commit

③調用底層 Connection#commit() 方法提交事務

Committing JDBC transaction on Connection [org.apache.commons.dbcp.PoolableConnection@dc41c5]

Triggering afterCommit synchronization

Triggering afterCompletion synchronization

Clearing transaction synchronization

嵌套事務

將ForumService#addTopic()設置爲PROPAGATION_REQUIRED 時，UserSerice#addCredits()設置爲PROPAGATION_REQUIRED、PROPAGATION_SUPPORTS、 PROPAGATION_MANDATORY時，運行的效果都是一致的（當然，如果單獨調用addCredits()就另當別論了）。

當addTopic()運行在一個事務下（如設置爲PROPAGATION_REQUIRED），而addCredits()設置爲 PROPAGATION_NESTED時，如果底層數據源支持保存點，Spring將爲內部的addCredits()方法產生的一個內嵌的事務。如果 addCredits()對應的內嵌事務執行失敗，事務將回滾到addCredits()方法執行前的點，並不會將整個事務回滾。內嵌事務是內層事務的一部分，所以只有外層事務提交時，嵌套事務才能一併提交。

嵌套事務不能夠提交，它必須通過外層事務來完成提交的動作，外層事務的回滾也會造成內部事務的回滾。

嵌套事務和新事務

PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED也是容易混淆的兩個傳播行爲。PROPAGATION_REQUIRES_NEW 啓動一個新的、和外層事務無關的“內部”事務。該事務擁有自己的獨立隔離級別和鎖，不依賴於外部事務，獨立地提交和回滾。當內部事務開始執行時，外部事務將被掛起，內務事務結束時，外部事務才繼續執行。

由此可見， PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大區別在於：PROPAGATION_REQUIRES_NEW 將創建一個全新的事務，它和外層事務沒有任何關係，而 PROPAGATION_NESTED 將創建一個依賴於外層事務的子事務，當外層事務提交或回滾時，子事務也會連帶提交和回滾。

其它需要注意問題

以下幾個問題值得注意：

1) 當業務方法被設置爲PROPAGATION_MANDATORY時，它就不能被非事務的業務方法調用。如將 ForumService#addTopic()設置爲PROPAGATION_MANDATORY，如果展現層的Action直接調用 addTopic()方法，將引發一個異常。正確的情況是：addTopic()方法必須被另一個帶事務的業務方法調用（如 ForumService#otherMethod()）。所以PROPAGATION_MANDATORY的方法一般都是被其它業務方法間接調用的。

2) 當業務方法被設置爲PROPAGATION_NEVER時，它將不能被擁有事務的其它業務方法調用。假設 UserService#addCredits()設置爲PROPAGATION_NEVER，當ForumService# addTopic()擁有一個事務時，addCredits()方法將拋出異常。所以PROPAGATION_NEVER方法一般是被直接調用的。

3)當方法被設置爲PROPAGATION_NOT_SUPPORTED時，外層業務方法的事務會被掛起，當內部方法運行完成後，外層方法的事務重新運行。如果外層方法沒有事務，直接運行，不需要做任何其它的事。

小結

在Spring聲明式事務管理的配置中，事務傳播行爲是最容易被誤解的配置項，原因在於事務傳播行爲名稱（如 PROPAGATION_NESTED：嵌套式事務）和代碼結構的類似性上（業務類方法嵌套調用另一個業務類方法）。這種誤解在很多Spring開發者中廣泛存在，本文深入講解了Spring事務傳播行爲對業務方法嵌套調用的真實影響，希望能幫助讀者化解對事務傳播行爲的困惑。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Spring 聲明式事務管理源碼解讀之事務提交

簡介：上次說到spring 聲明式事務管理的事務開始部分，按流程來講，下面應該提交事務了， spring 的聲明式事務管理其實是比較複雜的，事實上這種複雜性正是由於事務本身的複雜性導致的，如果能用兩三句話就把這部分內容說清楚是不現實的，也是不成熟的，而我對這部分的理解也可能是不全面的，還是那句話，希望大家和我一起把本貼的質量提交起來。
在下面的文章中，我講會多次提到第一篇文章，第一篇文章的地址是：http://www.javaeye.com/topic/87426
如果要理解事務提交的話，理解事務開始是一個前提條件,所以請先看第一篇文章，再來看這篇
如果你仔細看下去，我想肯定是有很多收穫，因爲我們確實能從spring 的代碼和思想中學到很多東西。

正文：

其實俺的感覺就是事務提交要比事務開始複雜，看事務是否提交我們還是要回到TransactionInterceptor類的invoke方法

代碼

在spring中使用聲明型事務

用 Spring 框架指定自定義隔離級別