Spring事務管理只對出現運行期異常進行回滾

使用spring不免要用到spring的事務管理，要用事務管理又會很天然的選擇聲明式的事務管理，在spring的文檔中說道，spring聲明式事務管理默認對非檢查型異常和運行時異常進行事務回滾，而對檢查型異常則不進行回滾操做。
那麼什麼是檢查型異常什麼又是非檢查型異常呢？
最簡單的判斷點有兩個：
1.繼承自runtimeexception或error的是非檢查型異常，而繼承自exception的則是檢查型異常（固然，runtimeexception自己也是exception的子類）。

2.對非檢查型類異常能夠不用捕獲，而檢查型異常則必須用try語句塊進行處理或者把異常交給上級方法處理總之就是必須寫代碼處理它。因此必須在service捕獲異常，而後再次拋出，這樣事務方纔起效。

結論：

在spring的事務管理環境下，使用unckecked exception能夠極大地簡化異常的處理，只須要在事務層聲明可能拋出的異常（這裏的異常能夠是自定義的unckecked exception體系），在全部的中間層都只是須要簡單throws便可，不須要捕捉和處理，直接到最高層，好比UI層再進行異常的捕捉和處理

在service類前加上@Transactional，聲明這個service全部方法須要事務管理。每個業務方法開始時都會打開一個事務。

Spring默認狀況下會對運行期例外(RunTimeException)進行事務回滾。這個例外是unchecked

若是遇到checked意外就不回滾。

如何改變默認規則：

1 讓checked例外也回滾：在整個方法前加上 @Transactional(rollbackFor=Exception.class)

2 讓unchecked例外不回滾： @Transactional(notRollbackFor=RunTimeException.class)

3 不須要事務管理的(只查詢的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)

 

注意： 若是異常被try｛｝catch｛｝了，事務就不回滾了，若是想讓事務回滾必須再往外拋try｛｝catch｛throw Exception｝。

一 個統一的異常層次結構對於提供服務抽象是必需的。 最重要的就是org.springframework.dao.DataAccessException以及其子類了。 須要強調的是Spring的異常機制重點在於應用編程模型。與SqlException和其餘數據存取API不一樣的是: Spring的異常機制是爲了讓開發者使用最少, 最清晰的代碼。DataAccessException和其餘底層異常都是非檢查性異常(unchecked exception)。 spring的原則之一就是基層異常就應該是非檢查性異常. 緣由以下: 
1. 基層異常一般來講是不可恢復的。 
2. 檢查性異常將會下降異常層次結構的價值.若是底層異常是檢查性的, 那麼就須要在全部地方添加catch語句進行捕獲。 
3.try/catch代碼塊冗長混亂, 並且不增長多少價值。 
使用檢查異常理論上很好, 可是實際上好象並不如此。 
Hibernate3也將從檢查性異常轉爲非檢查性異常。