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也將從檢查性異常轉為非檢查性異常。