Java 基礎之事務詳細介紹

更新時間：2017年03月15日 15:29:43 投稿：lqh

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

java 事務詳解

一、什么是事務

　　事務是訪問數(shù)據(jù)庫的一個操作序列，數(shù)據(jù)庫應用系統(tǒng)通過事務集來完成對數(shù)據(jù)庫的存取。事務的正確執(zhí)行使得數(shù)據(jù)庫從一種狀態(tài)轉換成另一種狀態(tài)。

　　事務必須服從ISO/IEC所制定的ACID原則。ACID是原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（durability）的縮寫事務必須服從ISO/IEC所制定的ACID原則。ACID是原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（durability）的縮寫。

原子性。即不可分割性，事務要么全部被執(zhí)行，要么就全部不被執(zhí)行。如果事務的所有子事務全部提交成功，則所有的數(shù)據(jù)庫操作被提交，數(shù)據(jù)庫狀態(tài)發(fā)生轉換；如果有子事務失敗，則其他子事務的數(shù)據(jù)庫操作被回滾，即數(shù)據(jù)庫回到事務執(zhí)行前的狀態(tài)，不會發(fā)生狀態(tài)轉換。

一致性或可串性。事務的執(zhí)行使得數(shù)據(jù)庫從一種正確狀態(tài)轉換成另一種正確狀態(tài)。
隔離性。在事務正確提交之前，不允許把該事務對數(shù)據(jù)的任何改變提供給任何其他事務，即在事務正確提交之前，它可能的結果不應顯示給任何其他事務。

持久性。事務正確提交后，其結果將永久保存在數(shù)據(jù)庫中，即使在事務提交后有了其他故障，事務的處理結果也會得到保存。　　

　　運行嵌入式SQL應用程序或腳本，在可執(zhí)行SQL語句第一次執(zhí)行時(在建立與數(shù)據(jù)庫的連接之后或在現(xiàn)有事務終止之后)，事務就會自動啟動。在啟動事務之后，必須由啟動事務的用戶或應用程序顯式地終止它，除非使用了稱為自動提交(automatic commit)的過程(在這種情況下，發(fā)出的每個單獨的SQL語句被看做單個事務，它一執(zhí)行就被隱式地提交了)。

　　在大多數(shù)情況下，通過執(zhí)行COMMIT或ROLLBACK語句來終止事務。當執(zhí)行COMMIT語句時，自從事務啟動以來對數(shù)據(jù)庫所做的一切更改就成為永久性的了-- 即它們被寫到磁盤。當執(zhí)行ROLLBACK語句時，自從事務啟動以來對數(shù)據(jù)庫所做的一切更改都被撤銷，并且數(shù)據(jù)庫返回到事務開始之前所處的狀態(tài)。不管是哪種情況，數(shù)據(jù)庫在事務完成時都保證能回到一致狀態(tài)。

　　一定要注意一點：雖然事務通過確保對數(shù)據(jù)的更改僅在事務被成功提交之后才成為永久性的，從而提供了一般的數(shù)據(jù)庫一致性，但還是須要用戶或應用程序來確保每個事務中執(zhí)行的SQL操作序列始終會導致一致的數(shù)據(jù)庫。

二、數(shù)據(jù)庫系統(tǒng)支持兩種事務模式：

自動提交模式：每個SQL語句都是一個獨立的事務，當數(shù)據(jù)庫系統(tǒng)執(zhí)行完一個SQL語句后，會自動提交事務。
手動提交模式：必須由數(shù)據(jù)庫客戶程序顯示指定事務開始邊界和結束邊界。

　　注：MySQL中數(shù)據(jù)庫表分為3種類型：INNODB、BDB和MyISAM，其中MyISAM不支持數(shù)據(jù)庫事務。MySQL中create table 語句默認為MyISAM類型?！?/p>

三、對于同時運行的多個事務，當這些事務訪問數(shù)據(jù)庫中相同的數(shù)據(jù)時，如果沒有采取必要的隔離機制，就會導致各種并發(fā)問題，這些并發(fā)問題可歸納為以下幾類：

第一類丟失更新：撤銷一個事務時，把其他事務已提交的更新數(shù)據(jù)覆蓋?！?/li>
臟讀：一個事務讀到另一個事務為提交的更新數(shù)據(jù)。
虛讀：一個事務讀到另一個事務已提交的新插入的數(shù)據(jù)。
不可重復讀：一個事務讀到另一個事務已提交的更新數(shù)據(jù)。
第二類丟失更新：這是不可重復讀中的特例，一個事務覆蓋另一個事務已提交的更新數(shù)據(jù)?！　?br />

四、隔離級別

　　當數(shù)據(jù)庫系統(tǒng)采用read Commited隔離級別時，會導致不可重復讀喝第二類丟失更新的并發(fā)問題，可以在應用程序中采用悲觀鎖或樂觀鎖來避免這類問題。從應用程序的角度，鎖可以分為以下幾類：

Serializable(串行化)：一個事務在執(zhí)行過程中完全看不到其他事務對數(shù)據(jù)庫所做的更新。
Repeatable Read(可重復讀)：一個事務在執(zhí)行過程中可以看到其他事務已經(jīng)提交的新插入的記錄，但是不能看到其他事務對已有記錄的更新。
Read Commited（讀已提交數(shù)據(jù)）：一個事務在執(zhí)行過程中可以看到其他事務已經(jīng)提交的新插入的記錄，而且能看到其他事務已經(jīng)提交的對已有記錄的更新
Read Uncomitted（讀未提交數(shù)據(jù)）：一個事務在執(zhí)行過程中可以拷打其他事務沒有提交的新插入的記錄，而且能看到其他事務沒有提交的對已有記錄的更新。

隔離級別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對并發(fā)性能的影響也越大。對于多數(shù)應用程序，可以有優(yōu)先考慮把數(shù)據(jù)庫系統(tǒng)的隔離級別設為Read Commited，它能夠避免臟讀，而且具有較好的并發(fā)性能。盡管它會導致不可重復讀、虛讀和第二類丟失更新這些并發(fā)問題，在可能出現(xiàn)這類問題的個別場合，可以由應用程序采用悲觀鎖或樂觀鎖來控制。

　　當數(shù)據(jù)庫系統(tǒng)采用read Commited隔離級別時，會導致不可重復讀喝第二類丟失更新的并發(fā)問題，可以在應用程序中采用悲觀鎖或樂觀鎖來避免這類問題。從應用程序的角度，鎖可以分為以下幾類：

　　A.悲觀鎖：指在應用程序中顯示的為數(shù)據(jù)資源加鎖。盡管能防止丟失更新和不可重復讀這類并發(fā)問題，但是它會影響并發(fā)性能，因此應該謹慎地使用。

　　B.樂觀鎖：樂觀鎖假定當前事務操作數(shù)據(jù)資源時，不回有其他事務同時訪問該數(shù)據(jù)資源，因此完全依靠數(shù)據(jù)庫的隔離級別來自動管理鎖的工作。應用程序采用版本控制手段來避免可能出現(xiàn)的并發(fā)問題。

五、悲觀鎖有兩種實現(xiàn)方式。

　　A.在應用程序中顯示指定采用數(shù)據(jù)庫系統(tǒng)的獨占所來鎖定數(shù)據(jù)資源。SQL語句：select ... for update，在hibernate中使用get，load時如session.get(Account.class,new Long(1),LockMode,UPGRADE)

　　B.在數(shù)據(jù)庫表中增加一個表明記錄狀態(tài)的LOCK字段，當它取值為“Y”時，表示該記錄已經(jīng)被某個事務鎖定，如果為“N”，表明該記錄處于空閑狀態(tài)，事務可以訪問它。增加鎖標記字段就可以實現(xiàn)。

　　利用Hibernate的版本控制來實現(xiàn)樂觀鎖

　　樂觀鎖是由程序提供的一種機制，這種機制既能保證多個事務并發(fā)訪問數(shù)據(jù)，又能防止第二類丟失更新問題。

　　在應用程序中可以利用Hibernate提供的版本控制功能來視線樂觀鎖，OR映射文件中的<version>元素和<timestamp>都具有版本控制的功能，一般推薦采用<version>

感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！

您可能感興趣的文章: