標籤:
From:http://www.cnblogs.com/kristain/articles/2038397.html
一、什麼是事務
事務是訪問資料庫的一個操作序列,資料庫應用系統通過事務集來完成對資料庫的存取。事務的正確執行使得資料庫從一種狀態轉換成另一種狀態。 事務必須服從ISO/IEC所制定的ACID原則。ACID是原子性(atomicity)、一致性(consistency)、隔離性(isolation)和持久性(durability)的縮寫事務必須服從ISO/IEC所制定的ACID原則。ACID是原子性(atomicity)、一致性(consistency)、隔離性(isolation)和持久性(durability)的縮寫。
- 原子性。即不可分割性,事務要麼全部被執行,要麼就全部不被執行。如果事務的所有子事務全部提交成功,則所有的資料庫操作被提交,資料庫狀態發生轉換;如果有子事務失敗,則其他子事務的資料庫操作被復原,即資料庫回到事務執行前的狀態,不會發生狀態轉換。
- 一致性或可串性。事務的執行使得資料庫從一種正確狀態轉換成另一種正確狀態。
- 隔離性。在事務正確提交之前,不允許把該事務對資料的任何改變提供給任何其他事務,即在事務正確提交之前,它可能的結果不應顯示給任何其他事務。
- 持久性。事務正確提交後,其結果將永久儲存在資料庫中,即使在事務提交後有了其他故障,事務的處理結果也會得到儲存。
運行嵌入式SQL應用程式或指令碼,在可執行SQL語句第一次執行時(在建立與資料庫的串連之後或在現有事務終止之後),事務就會自動啟動。在啟動事務之後,必須由啟動事務的使用者或應用程式顯式地終止它,除非使用了稱為自動認可(automatic commit)的過程(在這種情況下,發出的每個單獨的SQL語句被看做單個事務,它一執行就被隱式地提交了)。
在大多數情況下,通過執行COMMIT或ROLLBACK語句來終止事務。當執行COMMIT語句時,自從事務啟動以來對資料庫所做的一切更改就成為永久性的了-- 即它們被寫到磁碟。當執行ROLLBACK語句時,自從事務啟動以來對資料庫所做的一切更改都被撤銷,並且資料庫返回到事務開始之前所處的狀態。不管是哪種情況,資料庫在事務完成時都保證能回到一致狀態。
一定要注意一點:雖然事務通過確保對資料的更改僅在事務被成功提交之後才成為永久性的,從而提供了一般的資料庫一致性,但還是須要使用者或應用程式來確保每個事務中執行的SQL操作序列始終會導致一致的資料庫。
二、資料庫系統支援兩種事務模式:
- 自動認可模式:每個SQL語句都是一個獨立的事務,當資料庫系統執行完一個SQL語句後,會自動認可事務。
- 手動提交模式:必須由資料庫客戶程式顯示指定事務開始邊界和結束邊界。
註:MySQL中資料庫表分為3種類型:INNODB、BDB和MyISAM,其中MyISAM不支援資料庫事務。MySQL中create table 語句預設為MyISAM類型。
三、對於同時啟動並執行多個事務,當這些事務訪問資料庫中相同的資料時,如果沒有採取必要的隔離機制,就會導致各種並發問題,這些並發問題可歸納為以下幾類:
- 第一類丟失更新:撤銷一個事務時,把其他事務已提交的更新資料覆蓋。
- 髒讀:一個事務讀到另一個事務為提交的更新資料。
- 虛讀:一個事務讀到另一個事務已提交的新插入的資料。
- 不可重複讀取:一個事務讀到另一個事務已提交的更新資料。
- 第二類丟失更新:這是不可重複讀取中的特例,一個事務覆蓋另一個事務已提交的更新資料。
四、隔離等級
當資料庫系統採用read Commited隔離等級時,會導致不可重複讀取喝第二類丟失更新的並發問題,可以在應用程式中採用悲觀鎖或樂觀鎖來避免這類問題。從應用程式的角度,鎖可以分為以下幾類:
- Serializable(序列化):一個事務在執行過程中完全看不到其他事務對資料庫所做的更新。
- Repeatable Read(可重複讀):一個事務在執行過程中可以看到其他事務已經提交的新插入的記錄,但是不能看到其他事務對已有記錄的更新。
- Read Commited(讀已提交資料):一個事務在執行過程中可以看到其他事務已經提交的新插入的記錄,而且能看到其他事務已經提交的對已有記錄的更新
- Read Uncomitted(讀未提交資料):一個事務在執行過程中可以拷打其他事務沒有提交的新插入的記錄,而且能看到其他事務沒有提交的對已有記錄的更新。
隔離等級越高,越能保證資料的完整性和一致性,但是對並發效能的影響也越大。對於多數應用程式,可以有優先考慮把資料庫系統的隔離等級設為Read Commited,它能夠避免髒讀,而且具有較好的並發效能。儘管它會導致不可重複讀取、虛讀和第二類丟失更新這些並發問題,在可能出現這類問題的個別場合,可以由應用程式採用悲觀鎖或樂觀鎖來控制。
當資料庫系統採用read Commited隔離等級時,會導致不可重複讀取喝第二類丟失更新的並發問題,可以在應用程式中採用悲觀鎖或樂觀鎖來避免這類問題。從應用程式的角度,鎖可以分為以下幾類:
A.悲觀鎖:指在應用程式中顯示的為資料資源加鎖。儘管能防止丟失更新和不可重複讀取這類並發問題,但是它會影響並發效能,因此應該謹慎地使用。
B.樂觀鎖:樂觀鎖假定當前事務操作資料資源時,不回有其他事務同時訪問該資料資源,因此完全依靠資料庫的隔離等級來自動管理鎖的工作。應用程式採用版本控制手段來避免可能出現的並發問題。
五、悲觀鎖有兩種實現方式。
A.在應用程式中顯示指定採用資料庫系統的獨佔所來鎖定資料資源。SQL語句:select ... for update,在Hibernate中使用get,load時如session.get(Account.class,new Long(1),LockMode,UPGRADE)
B.在資料庫表中增加一個表明選項組的LOCK欄位,當它取值為“Y”時,表示該記錄已經被某個事務鎖定,如果為“N”,表明該記錄處於空閑狀態,事務可以訪問它。增加鎖標記欄位就可以實現。
利用Hibernate的版本控制來實現樂觀鎖
樂觀鎖是由程式提供的一種機制,這種機制既能保證多個事務並發訪問資料,又能防止第二類丟失更新問題。
在應用程式中可以利用Hibernate提供的版本控制功能來視線樂觀鎖,OR對應檔中的<version>元素和<timestamp>都具有版本控制的功能,一般推薦採用<version>
JAVA事務的概念