事務配置步驟:
1、首先在lydwz-ds-applicationContext.xml配置文件中增長如下內容:
<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
java
前一段時間,項目代碼評審,發現有TX不使用Spring的事務處理,而直接封裝方法,手動進行數據的回滾,得悉緣由是:拋出異常之後事務不起做用,沒有回滾。這理由頓時讓人很無語,不過還算個聰明的TX,知曉另闢蹊徑,可是在insert的時候,手動回滾直接delete就能夠了,若是是update,不曉得還會有什麼更犀利的辦法。
仔細評審代碼細節,發現該TX壓根沒有按照框架原先設計在service層throws BusinessException,而是直接throws Exception。Spring配置異常回滾採用的是rollback-for=「BusinessException」。TX提出疑問:Spring不是拋出異常事務就會回滾麼?帶着疑問,查閱資料,分析源代碼,最終找到想要的答案。這一切來源於java的檢查性異常、非檢查性異常的區別。
使用spring不免要用到spring的事務管理,要用事務管理又會很天然的選擇聲明式的事務管理,在spring的文檔中說道,spring聲明式事務管理默認對非檢查型異常和運行時異常進行事務回滾,而對檢查型異常則不進行回滾操做。
那麼什麼是檢查型異常什麼又是非檢查型異常呢?
最簡單的判斷點有兩個:
1.繼承自runtimeexception或error的是非檢查型異常,而繼承自exception的則是檢查型異常(固然,runtimeexception自己也是exception的子類)。
2.對非檢查型類異常能夠不用捕獲,而檢查型異常則必須用try語句塊進行處理或者把異常交給上級方法處理總之就是必須寫代碼處理它。因此必須在service捕獲異常,而後再次拋出,這樣事務方纔起效。spring
2、自定義異常類:LydException 繼承:RuntimeException
app
3、service方法配置:
一、方法一:
直接在方法前增長如下內容:
@Transactional(readOnly = false, propagation = Propagation.REQUIRED, rollbackFor = LydException.class)
二、方法二:
直接在方法前增長如下內容:
@Transactional(readOnly = false, propagation = Propagation.REQUIRED)
並在方法內try catch 拋出自定義LydException異常:
try {
} catch (Exception e) {
e.printStackTrace();
throw new LydException("請注意,您所作的操做是非法操做");
}
框架