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隔離級別時，會導致不可重復讀喝第二類丟失更新的並發問題，可以在應用程序中采用悲觀鎖或樂觀鎖來避免這類問題。從應用程序的角度，鎖可以分為以下幾類：
- 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事務的概念