事務是訪問數據庫的一個操做序列，數據庫應用系統經過事務集來完成對數據庫的存取。事務的正確執行使得數據庫從一種狀態轉換成另外一種狀態。
 
　　事務必須服從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語句時，自從事務啓動以來對數據庫所作的一切更改都被撤銷，而且數據庫返回到事務開始以前所處的狀態。不論是哪一種狀況，數據庫在事務完成時都保證能回到一致狀態。session

　　必定要注意一點：雖然事務經過確保對數據的更改僅在事務被成功提交以後才成爲永久性的，從而提供了通常的數據庫一致性，但仍是需要用戶或應用程序來確保每一個事務中執行的SQL操做序列始終會致使一致的數據庫。併發

 

2、數據庫系統支持兩種事務模式：post

  • 自動提交模式：每一個SQL語句都是一個獨立的事務，當數據庫系統執行完一個SQL語句後，會自動提交事務。
  • 手動提交模式：必須由數據庫客戶程序顯示指定事務開始邊界和結束邊界。

　　注：MySQL中數據庫表分爲3種類型：INNODB、BDB和MyISAM，其中MyISAM不支持數據庫事務。MySQL中create table 語句默認爲MyISAM類型。性能

　　

3、對於同時運行的多個事務，當這些事務訪問數據庫中相同的數據時，若是沒有采起必要的隔離機制，就會致使各類併發問題，這些併發問題可概括爲如下幾類：atom

  • 第一類丟失更新：撤銷一個事務時，把其餘事務已提交的更新數據覆蓋。　
  • 髒讀：一個事務讀到另外一個事務爲提交的更新數據。
  • 虛讀：一個事務讀到另外一個事務已提交的新插入的數據。
  • 不可重複讀：一個事務讀到另外一個事務已提交的更新數據。
  • 第二類丟失更新：這是不可重複讀中的特例，一個事務覆蓋另外一個事務已提交的更新數據。　　

　

4、隔離級別版本控制

 

 

 

　　當數據庫系統採用read Commited隔離級別時，會致使不可重複讀喝第二類丟失更新的併發問題，能夠在應用程序中採用悲觀鎖或樂觀鎖來避免這類問題。從應用程序的角度，鎖能夠分爲如下幾類：blog

  • Serializable(串行化)：一個事務在執行過程當中徹底看不到其餘事務對數據庫所作的更新。
  • Repeatable Read(可重複讀)：一個事務在執行過程當中能夠看到其餘事務已經提交的新插入的記錄，可是不能看到其餘事務對已有記錄的更新。
  • Read Commited（讀已提交數據）：一個事務在執行過程當中能夠看到其餘事務已經提交的新插入的記錄，並且能看到其餘事務已經提交的對已有記錄的更新
  • Read Uncomitted（讀未提交數據）：一個事務在執行過程當中能夠拷打其餘事務沒有提交的新插入的記錄，並且能看到其餘事務沒有提交的對已有記錄的更新。

    隔離級別越高，越能保證數據的完整性和一致性，可是對併發性能的影響也越大。對於多數應用程序，能夠有優先考慮把數據庫系統的隔離級別設爲Read Commited，它可以避免髒讀，並且具備較好的併發性能。儘管它會致使不可重複讀、虛讀和第二類丟失更新這些併發問題，在可能出現這類問題的個別場合，能夠由應用程序採用悲觀鎖或樂觀鎖來控制。事務

　　當數據庫系統採用read Commited隔離級別時，會致使不可重複讀喝第二類丟失更新的併發問題，能夠在應用程序中採用悲觀鎖或樂觀鎖來避免這類問題。從應用程序的角度，鎖能夠分爲如下幾類：ci

　　A.悲觀鎖：指在應用程序中顯示的爲數據資源加鎖。儘管能防止丟失更新和不可重複讀這類併發問題，可是它會影響併發性能，所以應該謹慎地使用。 

　　B.樂觀鎖：樂觀鎖假定當前事務操做數據資源時，不回有其餘事務同時訪問該數據資源，所以徹底依靠數據庫的隔離級別來自動管理鎖的工做。應用程序採用版本控制手段來避免可能出現的併發問題。

5、悲觀鎖有兩種實現方式。

　　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>