轉自 https://blog.csdn.net/zht741322694/article/details/78676964
一、spring支持的事務聲明方式
1. 編程式事務 當系統需要明確的，細粒度的控制各個事務的邊界，應選擇編程式事務。
2. 聲明式事務 當系統對於事務的控制粒度較粗時，應該選擇申明式事務，通過<tx>標簽和<aop>切面形式在xml中進行配置。
3. 無論你選擇上述何種事務方式去實現事務控制，spring都提供基於門面設計模式的事務管理器供選擇，如下是spring事務中支持的事務管理器
事務管理器實現(org.springframework.*)
使用時機
jdbc.datasource.DataSourceTransactionManager
使用jdbc的抽象以及ibatis支持
orm.hibernate.HibernateTransactionManager
使用hibernate支持(默認3.0以下版本)
orm.hibernate3.HibernateTransactionManager
使用hibernate3支持
transaction.jta.JtaTransactionManager
使用分布式事務（分布式數據庫支持）
orm.jpa.JpaTransactionManager
使用jpa做為持久化工具
orm.toplink.TopLinkTransactionManager
使用TopLink持久化工具
orm.jdo.JdoTransactionManager
使用Jdo持久化工具
jms.connection.JmsTransactionManager
使用JMS 1.1+
jms.connection.JmsTransactionManager102
使用JMS 1.0.2
transaction.jta.OC4JJtaTransactionManager
使用oracle的OC4J JEE容器
transaction.jta.WebLogicJtaTransactionManager
在weblogic中使用分布式數據庫
jca.cci.connection.CciLocalTransactionManager
使用jrping對J2EE Connector Architecture (JCA)和Common Client Interface (CCI)的支持
配置示例如下:
<bean id="transactionManager"class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<propertyname="dataSource" ref="dataSource"/> //引入數據源
</bean>
二、spring支持7種事務傳播行為
傳播行為
含義
propagation_required（xml文件中為required)
表示當前方法必須在一個具有事務的上下文中運行，如有客戶端有事務在進行，那么被調用端將在該事務中運行，否則的話重新開啟一個事務。（如果被調用端發生異常，那么調用端和被調用端事務都將回滾）
propagation_supports(xml文件中為supports）
表示當前方法不必需要具有一個事務上下文，但是如果有一個事務的話，它也可以在這個事務中運行
propagation_mandatory(xml文件中為mandatory）
表示當前方法必須在一個事務中運行，如果沒有事務，將拋出異常
propagation_nested(xml文件中為nested)
表示如果當前方法正有一個事務在運行中，則該方法應該運行在一個嵌套事務中，被嵌套的事務可以獨立於被封裝的事務中進行提交或者回滾。如果封裝事務存在，並且外層事務拋出異常回滾，那么內層事務必須回滾，反之，內層事務並不影響外層事務。如果封裝事務不存在，則同propagation_required的一樣
propagation_never（xml文件中為never)
表示當方法務不應該在一個事務中運行，如果存在一個事務，則拋出異常
propagation_requires_new(xml文件中為requires_new）
表示當前方法必須運行在它自己的事務中。一個新的事務將啟動，而且如果有一個現有的事務在運行的話，則這個方法將在運行期被掛起，直到新的事務提交或者回滾才恢復執行。
propagation_not_supported（xml文件中為not_supported）
表示該方法不應該在一個事務中運行。如果有一個事務正在運行，他將在運行期被掛起，直到這個事務提交或者回滾才恢復執行
三、spring中的事務隔離級別
隔離級別
含義
isolation_default
使用數據庫默認的事務隔離級別
isolation_read_uncommitted
允許讀取尚未提交的修改，可能導致臟讀、幻讀和不可重復讀
isolation_read_committed
允許從已經提交的事務讀取，可防止臟讀、但幻讀，不可重復讀仍然有可能發生
isolation_repeatable_read
對相同字段的多次讀取的結果是一致的，除非數據被當前事務自生修改。可防止臟讀和不可重復讀，但幻讀仍有可能發生
isolation_serializable
完全服從acid隔離原則，確保不發生臟讀、不可重復讀、和幻讀，但執行效率最低。
臟讀、不可重復讀、幻象讀概念說明：
a.臟讀：指當一個事務正字訪問數據，並且對數據進行了修改，而這種數據還沒有提交到數據庫中，這時，另外一個事務也訪問這個數據，然后使用了這個數據。因為這個數據還沒有提交那么另外一個事務讀取到的這個數據我們稱之為臟數據。依據臟數據所做的操作肯能是不正確的。
b.不可重復讀：指在一個事務內，多次讀同一數據。在這個事務還沒有執行結束，另外一個事務也訪問該同一數據，那么在第一個事務中的兩次讀取數據之間，由於第二個事務的修改第一個事務兩次讀到的數據可能是不一樣的，這樣就發生了在一個事物內兩次連續讀到的數據是不一樣的，這種情況被稱為是不可重復讀。
c.幻象讀：一個事務先后讀取一個范圍的記錄，但兩次讀取的紀錄數不同，我們稱之為幻象讀（兩次執行同一條 select 語句會出現不同的結果，第二次讀會增加一數據行，並沒有說這兩次執行是在同一個事務中）
四、spring事務只讀屬性
spring事務只讀的含義是指，如果后端數據庫發現當前事務為只讀事務，那么就會進行一系列的優化措施。它是在后端數據庫進行實施的，因此，只有對於那些有可能啟動一個新事務的傳播行為（REQUIRED,REQUIRES_NEW,NESTED）的方法來說，才有意義。（測試表明，當使用JDBC事務管理器並設置當前事務為只讀時，並不能發生預期的效果，即能執行刪除，更新，插入操作）
五、spring的事務超時
有的時候為了系統中關鍵部分的性能問題，它的事務執行時間應該盡可能的短。因此可以給這些事務設置超時時間，以秒為單位。我們知道事務的開始往往都會發生數據庫的表鎖或者被數據庫優化為行鎖，如果允許時間過長，那么這些數據會一直被鎖定，影響系統的並發性。
因為超時時鍾是在事務開始的時候啟動，因此只有對於那些有可能啟動新事物的傳播行為（REQUIRED,REQUIRES_NEW,NESTED）的方法來說，事務超時才有意義。
六、事務回滾規則
spring中可以指定當方法執行並拋出異常的時候，哪些異常回滾事務，哪些異常不回滾事務。默認情況下，只在方法拋出運行時異常的時候才回滾(runtime exception)。而在出現受阻異常(checked exception)時不回滾事務。當然可以采用申明的方式指定哪些受阻異常像運行時異常那樣指定事務回滾。
七、單個方法的事務傳播機制(注意這里說的是單個方法）
1、整備工作: spring申明式事務配置,將aop，tx命名空間添加到當前的spring配置文件頭中，這里不在累述
2、定義一個事務AOP通知(add開頭名單方法)
<tx:advice id="txAdvice" transactionManager="transactionManager">
<tx:attributes>
<tx:methodname="add*" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>
3、定義一個事務切面，即應該在哪些類的哪些方法上面進行事務切入，多個包體可以使用||隔開
<aop:config>
<aop:advisor pointcut="execution(* *..zx.spring.UserService*.*(..))||execution(**..spring.ServiceFacade.*(..))||execution(**..spring.BookService.*(..))"
advice-ref="txAdvice"/>
</aop:config>
4、事務通知中Propagation設置為7中傳播行為的情況如下(單方法):
@1、方法的事務傳播機制為REQUIRED， REQUIRES_NEW，並且拋出運行時異常時，將回滾事務。當方法拋出受檢查的異常時，將不會回滾事務。
@2、方法的事務傳播機制為MANDATORY，由於單個方法執行沒有指定任何事務傳播機制，因此拋出異常。
@3、方法的事務傳播機制為NESTED，由於NESTED內嵌事務，如果沒有外層事務，則新建一個事務，行為同REQUIRED一樣。
@4、方法的事務傳播機制為NEVER，由於發生運行時異常，事務本應該回滾，但是事務傳播機制為NEVER，因此找不到事務進行回滾。
@5、方法的事務傳播機制為NOT_SUPPORTED，單個方法被執行時，不會創建事務。如果當前有事務，將封裝事務掛起，知道該方法執行完成再恢復封裝事務，繼續執行。
@6、方法的事務傳播機制為SUPPORTS，單個方法 調用時supports行為同NEVER一樣，不會創建事務，只是如果有事務，則會加入到當前事務中去。
八、多個方法間的事務傳播機制(注意這里說的是多個方法)
1、整備工作: spring申明式事務配置,將aop，tx命名空間添加到當前的spring配置文件頭中，不在累述。
2、定義一個事務AOP通知(add開頭名單方法)
<tx:advice id="txAdvice" transactionManager="transactionManager">
<tx:attributes>
<tx:methodname="add*" propagation="REQUIRED"/>
<tx:methodname="update*" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>
3、定義一個事務切面，即應該在哪些類的哪些方法上面進行事務切入
<aop:config>
<aop:advisor pointcut="execution(**..zx.spring.UserService*.*(..))||execution(**..spring.ServiceFacade.*(..))||execution(**..spring.BookService.*(..))"
advice-ref="txAdvice"/>
</aop:config>
4、事務通知中Propagation設置為7中傳播行為的情況如下(多方法間傳遞):
@1、多個方法的事務傳播機制都為REQUIRED，由於REQUIRED方式是如果有一個事務，則加入事務中，如果沒有，則新建一個事務，也就是說方法1一開始就會創建一個事務，而方法2發現有事務存在則會加入到事務中，方法2拋出運行時異常,整個事務將會回滾。如果方法2拋出的是可捕獲異常，事務將不起作用，方法1執行成功插入，方法2異常中斷。或者我們將方法2設置rollback-for屬性，那么在指定的異常之內事務都將回滾
@2、方法1的事務傳播機制為REQUIRED，方法2的事務傳播機制為NEVER，由於方法1會創建一個事務，而方法2是NEVER,不應該在事務中運行，因此導致了沖突會報錯。Existingtransaction found for transaction marked with propagation 'never'
@3、方法1的事務傳播機制為REQUIRED，方法2的事務傳播機制為MANDATORY，執行機制和@1一致。
@4、方法1的事務傳播機制為REQUIRED，方法2的事務傳播機制為NESTED，內嵌事務，也就是方法1執行體內放入方法2的調用，由於方法2的事務傳播機制為NESTED內嵌事務，因此，開始一個新的事務。並且方法2內部拋出RuntimeException,因此內部嵌套事務回滾到外層事務創建的保存點。
注意這個地方，我們拋出的是運行時異常，如果我們拋出受檢查的異常，那么spring會默認的忽略此異常。
如果內層事務拋出檢查異常，那么外層事務將忽略此異常，但是會產生一個問題。那就是：外層事務使用jdbc的保存點API來實現嵌套事務，
但是數據庫不一定支持。我做測試的是oracle數據庫，jdbc事務管理器在內層事務拋出檢查異常后，將會在內層事務結束后，釋放外層事務創建的保存點，這個時候數據庫不一定支持。因此可能會拋出如下異常java.sql.SQLException:不支持的特性。
總結: 對於NESTED內層事務而言，內層事務獨立於外層事務，可以獨立遞交或者回滾,如果內層事務拋出的是運行異常，外層事務進行回滾，內層事務也會進行回滾。
@5、方法1的事務傳播機制為REQUIRED，方法2的事務傳播機制為REQUIRES_NEW。(情況比較復雜)
情況一，方法2不拋出任何異常下:方法1先創建事務，但是方法2也要運行在自己的事務中，因此也會創建一個事務，方法1的事務將會掛起，直到方法2的事務執行完成才會接着事務的提交完成
情況二，方法2拋出運行時異常下: 對於REQUIRES_NEW事務傳播機制，如果被調用端(方法2)拋出運行時異常，則被調用端事務回滾，如果調用段代碼(方法1)捕獲了被調用端拋出的運行時異常，那么調用端事務提交，不回滾。反之，如果調用段代碼未捕獲被調用端拋出的運行時異常，那么調用端事務回滾，不提交。
@6、方法1的事務傳播機制為REQUIRED，方法2的事務傳播機制為SUPPORTS，方法1創建一個事務，方法2加入到當前事務中，方法2拋出運行異常將進行事務的回滾，如果方法1不具有事務，由於方法2的特性是事務環境可有可無，方法2也不會運行在事務中，所以也不會進行回滾。如果方法2拋出的是受檢查異常，異常將會忽略，事務將會提交，當然還有別的情況沒有一一驗證
@7、方法1的事務傳播機制為REQUIRED，方法2的事務傳播機制為NOT_SUPPORTED，由於方法2事務特性，方法1的事務將會被掛起，方法2拋出運行時異常，但是方法2是不在事務環境中運行的，所以回滾不了，而方法1中未捕獲此異常，將進行事務回滾，如果方法2拋出的是運行異常，即使方法1沒有捕獲此異常，也將被忽略，不進行事務的回滾。
PS:以上都是對粗粒度的方法的事務操作，都是在數據無問題，特意拋出異常的情況下來判斷事務的特性，並在什么情況下事務將會起作用。而且spring的事務，在服務類內部的方法間調用，有可能存在被調用方法配置的事務不起作用，調用方在加上事務就起作用了。還值得測試深究
九、spring聲明式事務配置的幾種方式
1、基於@Transactional注解(推薦配置)
<!-- 事務管理器，對mybatis操作數據庫進行事務控制，spring使用jdbc的事務控制類 -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSourceSuport"></property>
</bean>
<!—開啟spring 事務注解支持 mode="aspectj"表示采用切面 mode="proxy"表示代理模式(默認) -->
<tx:annotation-driven transaction-manager="transactionManager" />
MyBatis自動參與到spring事務管理中，無需額外配置，只要org.mybatis.spring.SqlSessionFactoryBean引用的數據源與DataSourceTransactionManager引用的數據源一致即可，否則事務管理會不起作用。
@Transactional可以作用於接口、接口方法、類以及類方法上。當作用於類上時，該類的所有 public 方法將都具有該類型的事務屬性，同時，我們也可以在方法級別使用該標注來覆蓋類級別的定義。 雖然@Transactional 注解可以作用於接口、接口方法、類以及類方法上，但是 Spring 建議不要在接口或者接口方法上使用該注解，因為這只有在使用基於接口的代理時它才會生效。另外，@Transactional 注解應該只被應用到public 方法上，這是由 Spring AOP 的本質決定的。如果你在 protected、private 或者默認可見性的方法上使用@Transactional 注解，這將被忽略，也不會拋出任何異常。默認情況下，只有來自外部的方法調用才會被AOP代理捕獲，也就是，類內部方法調用本類內部的其他方法並不會引起事務行為，即使被調用方法使用@Transactional注解進行修飾。
2、基於<tx>與<aop>切面的方式進行事務配置
<!-- 事務管理器，對mybatis操作數據庫進行事務控制，spring使用jdbc的事務控制類 -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSourceSuport"></property>
</bean>
<!-- spring 事務注解 mode="aspectj"表示采用切面 mode="proxy"表示代理模式(默認) -->
<tx:annotation-driven transaction-manager="transactionManager" />
<!-- 通知 映射到上面的事務管理器-->
<tx:advice id="txAdive"transaction-manager="transactionManager">
<tx:attributes>
<!--name什么方法名稱開頭 傳播行為 REQUIRED必須事務 rollback-for什么異常類進行回滾，逗號隔開 -->
<tx:method name="save*" propagation="REQUIRED"rollback-for="java.lang.DaoException"/>
<tx:method name="delete*" propagation="REQUIRED"rollback-for="java.lang.DaoException"/>
<tx:method name="insert*" propagation="REQUIRED"rollback-for="java.lang.DaoException"/>
<tx:method name="update*" propagation="REQUIRED"rollback-for="java.lang.DaoException"/>
<!-- 不是必須的，而且查詢類型為事務只讀的可以提高數據庫性能優化 -->
<tx:method name="find*" propagation="SUPPORTS"read-only="true"/>
<tx:method name="get*" propagation="SUPPORTS"read-only="true"/>
<tx:method name="select*" propagation="SUPPORTS"read-only="true"/>
</tx:attributes>
</tx:advice>
<!-- aop切面並配置切入點入進行事物管理 指向上面的映射 -->
<aop:config>
<aop:pointcut expression="execution(* com.zht.service.serviceImpl.*.*(..))"id="txPointcut"/>
<aop:advisor advice-ref="txAdive" pointcut-ref="txPointcut"/>
</aop:config>
<aop:aspectj-autoproxy proxy-target-class="true"/>
3、基於TransactionProxyFactoryBean （bean工廠代理）--需要顯示的為每一個業務類配置，每多一個業務類就要進行添加，這里不在描述。
4、基於TransactionInterceptor（事務攔截器）的方式進行配置。
<bean id="transactionManager"class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<propertyname="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>
<!--事務攔截器,激活事務管理器所必須的bean -->
<bean id="transactionInterceptor"class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<!--配置事務屬性 -->
<property name="transactionAttributes">
<props>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
<!--定義事務處理代理bean,他需要兩個屬性,一個是指定需要代理的bean,另一個是代理bean所需的事務攔截器 -->
<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>tempService</value>
</list>
</property>
<propertyname="interceptorNames">
<list>
<value>transactionInterceptor</value>
</list>
</property>
</bean>
<!--業務邏輯層 -->
<bean id="tempService" class="com.cj.transaction.service.TempService"abstract="false"
lazy-init="default"autowire="default" dependency-check="default">
<property name="userDAO">
<ref bean="userDAO" />
</property>
<property name="deptDAO">
<ref bean="deptDAO" />
</property>
</bean>
<bean id="userDAO" class="com.cj.transaction.hibernate.UserDAO">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>
<bean id="deptDAO"class="com.cj.transaction.hibernate.DeptDAO">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>
如果模塊過多話，可以考慮根據bean的名稱用自動創建事務代理的方式
<!--自動代理 -->
<bean id="autoproxy"class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>*Service</value>
</list>
</property>
<property name="interceptorNames">
<list>
<value>transactionInterceptor</value>
</list>
</property>
</bean>
---------------------
作者：Yeah-小海
來源：CSDN
原文：https://blog.csdn.net/zht741322694/article/details/78676964
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！