Java基礎之事務的具體介紹

這篇文章主要介紹了Java 基礎之事務詳細介紹的相關資料,需要的朋友可以參考下

java 事務詳解

一、什麼是交易

　　事務是存取資料庫的一個操作序列，資料庫應用系統透過事務集來完成對資料庫的存取。交易的正確執行使得資料庫從一種狀態轉換成另一種狀態。

 　　事務必須服從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隔離等級時，會導致無法重複讀喝第二類遺失更新的並發問題，可以在應用程式中採用悲觀鎖或樂觀鎖來避免這類問題。從應用程式的角度，鎖定可以分為以下幾類：

1. Serializable(串行化)：一個交易在執行過程中完全看不到其他交易對資料庫所做的更新。

2. Repeatable Read(可重複讀取)：一個交易在執行過程中可以看到其他交易已經提交的新插入的記錄，但是不能看到其他交易對已有記錄的更新。

3. Read Commited（讀取已提交資料）：一個交易在執行過程中可以看到其他交易已經提交的新插入的記錄，並且能看到其他交易已經提交的對已有記錄的更新

4. 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映射檔案中的元素和<timestamp>都具有版本控制的功能，一般建議採用

以上是Java基礎之事務的具體介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！