Spring 和 JDBC 整合開發：（2）
通過JDBC模板類 處理 異常
處理 事務的傳播特性
處理事務的隔離性
| @Transactional(noRollbackFor=RuntimeException.class) public void save(User user) throws Exception{ // TODO Auto-generated method stub this.template.update("insert into user values(?,?)", new Object[]{new Integer(user.getId()),user.getName()}, new int[]{java.sql.Types.INTEGER,java.sql.Types.VARCHAR}); System.out.println("插入成功...."); throw new RuntimeException(); } |
我們制定了參數：noRollbackFor 所以 即使 遇到了運行期異常（nocheck異常）的時候 仍然不會回滾
Spring默認的是 只是 運行期異常才會回滾但是 我們這裡可以認為的指定哪些類 需要回滾事務
| @Transactional(rollbackFor=Exception.class) public void save(User user) throws Exception{ // TODO Auto-generated method stub this.template.update("insert into user values(?,?)", new Object[]{new Integer(user.getId()),user.getName()}, new int[]{java.sql.Types.INTEGER,java.sql.Types.VARCHAR}); System.out.println("插入成功...."); throw new Exception(); } |
此時 我們指定Exception異常要回滾 所以 執行結果是事務回滾了
下面是 事務傳播特性的 第一個例子：Required nerver給出代碼：
| @Transactional(propagation=Propagation. // System. userdao_1.save( } |
代碼二：
| @Transactional(propagation=Propagation. // System. } |
代碼一 需要事務 當執行到dao層是 檢測到沒有事務 所以 就 給分配了事務：但是 嵌套了一個方法,代碼二中的方法不需要事務PROPAGATION.NEVER但是 它運行在了事務環境中 所以 拋出異常
代碼二：運行在代碼一的事務環境中,出現了異常（此異常是RuntimeExcpetion的一個子類） 所以 全部回滾 一條數據 都沒有插入進；
強制：代碼一：
| @Transactional(propagation=Propagation. // System. userdao_1.save( } |
代碼二：
| @Transactional(propagation=Propagation. // System. } |
運行結果拋出異常：但是 代碼一不需要事務 運行完SQL 就對資料庫 修改了,但是代碼二需要事務 但是運行在沒有事務的環境下所以跑出了異常
支持：
| @Test BeanFactory bf = UserDAO dao =(UserDAO) bf.getBean("userdao"); User user = user.setId(11); user.setName("劉強"); dao.save(user); } |
代碼一：
| @Transactional(propagation=Propagation. // System. userdao_1.save( } |
代碼二：
| @Transactional(propagation=Propagation. // System. } |
第一個 不支持事務 它是運行在無事務的環境中所以 可以運行成功,代碼二 是suppoert 當沒有事務的時候就 在沒有事務的環境下運行
新的這個就不多說了,每次都分配一個新的事務嵌套傳播
| @Transactional(propagation=Propagation. // System. userdao_1.save( } // } } |
代碼二：
| @Transactional(propagation=Propagation. // System. } 這裡 是下面類似： ************************************************************************* 在這篇文章里,他用兩個嵌套的例子輔助分析,我這裡直接引用了. ServiceA { /** * 事務屬性配置為 */ void methodA() { ServiceB.methodB(); } } ServiceB { /** * 事務屬性配置為 */ void methodB() { } } ************************************************* |
我看這個還不太理解,覺得如果你都用try catch 給把異常捕獲了,就肯定不會拋異常事務就肯定可以完成這樣不覺得有什麼多神秘的區別
事務的隔離級別：四種隔離級別：第一種：代碼一：COMMITTED
| @Transactional(isolation=Isolation. // @Override // User user = user.setId(resultset.getInt("id")); user.setName(resultset.getString("name")); } }); } |
代碼二：
| public // System. } |
這種類型是只可以讀取 提交了事務的數據 這裡如果 代碼二打一個斷點 保存ID為3的用戶,當運行在方法結束 停止,然後 運行取ID為3的數據的操作 ,結果 失敗了 事務沒有提交 查詢不到ID 為三的用戶
第二種UNCOMMITTED代碼和上面的一樣 ,把隔離級別換了就可以,…… 結果可以取得數據出現了所謂的「 臟讀」
第三種REPEATABLE_READ可以重複讀
具體看下面的了
1. 臟讀（事務沒提交,提前讀取）：臟讀就是指當一個事務正在訪問數據,並且對數據進行了修改,而這種修改還沒有提交到資料庫中,這時,另外一個事務也訪問這個數據,然後使用了這個數據.
2. 不可重複讀（兩次讀的不一致） ：是指在一個事務內,多次讀同一數據.在這個事務還沒有結束時,另外一個事務也訪問該同一數據.那麼,在第一個事務中的兩次讀數據之間,由於第二個事務的修改,那麼第一個事務兩次讀到的的數據可能是不一樣的.這樣就發生了在一個事務內兩次讀到的數據是不一樣的,因此稱為是不可重複讀.例如,一個編輯人員兩次讀取同一文檔,但在兩次讀取之間,作者重寫了該文檔.當編輯人員第二次讀取文檔時,文檔已更改.原始讀取不可重複.如果只有在作者全部完成編寫后編輯人員才可以讀取文檔,則可以避免該問題.
3.幻讀 ： 是指當事務不是獨立執行時發生的一種現象,例如第一個事務對一個表中的數據進行了修改,這種修改涉及到表中的全部數據行.同時,第二個事務也修改這個表中的數據,這種修改是向表中插入一行新數據.那麼,以後就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行,就好象發生了幻覺一樣.例如,一個編輯人員更改作者提交的文檔,但當生產部門將其更改內容合併到該文檔的主複本時,發現作者已將未編輯的新材料添加到該文檔中.如果在編輯人員和生產部門完成對原始文檔的處理之前,任何人都不能將新材料添加到文檔中,則可以避免該問題.
4.第一類更新丟失（回滾丟失）：當2個事務更新相同的數據源,如果第一個事務被提交,而另外一個事務卻被撤銷,那麼會連同第一個事務所做的跟新也被撤銷.也就是說第一個事務做的跟新丟失了.
5.第二類更新丟失（覆蓋丟失）：第二類更新丟失實在實際應用中經常遇到的併發問題,他和不可重複讀本質上是同一類併發問題,通常他被看做不可重複讀的特例：當2個或這個多個事務查詢同樣的記錄然後各自基於最初的查詢結果更新該行時,會造成第二類丟失更新.每個事務都不知道不知道其他事務的存在,
一個事務對記錄做的修改將覆蓋其他事務對該記錄做的已提交的跟新……
補充 ： 基於元數據的 Spring 聲明性事務 ：
Isolation 屬性一共支持五種事務設置,具體介紹如下：
l DEFAULT 使用資料庫設置的隔離級別 （ 默認 ） ,由 DBA 默認的設置來決定隔離級別 .
l READ_UNCOMMITTED 會出現臟讀、不可重複讀、幻讀 （ 隔離級別最低,併發性能高 ）
l READ_COMMITTED 會出現不可重複讀、幻讀問題（鎖定正在讀取的行）
l REPEATABLE_READ 會出幻讀（鎖定所讀取的所有行）
l SERIALIZABLE 保證所有的情況不會發生（鎖表）
不可重複讀的重點是修改 ：
同樣的條件 , 你讀取過的數據 , 再次讀取出來發現值不一樣了
幻讀的重點在於新增或者刪除
同樣的條件 , 第 1 次和第 2 次讀出來的記錄數不一樣
[火星人 ] Spring JDBC事務 傳播特性已經有1071次圍觀
