如何防止髒讀、不可重複讀、幻讀

[轉自]http://blog.csdn.net/gaoshan_820822/article/details/4582561

鎖就是防止其他事務訪問指定的資源的手段。鎖是實現併發控制的主要方法，是多個用戶能夠同時操縱同一個數據庫中的數據而不發生數據不一致現象的重要保障。 一般來說，鎖可以防止髒讀、不可重複讀和幻覺讀。

 

事務併發產生的問題：
        髒讀：一個事務讀取到了另外一個事務沒有提交的數據
            事務1：更新一條數據
                             ------------->事務2：讀取事務1更新的記錄
            事務1：調用commit進行提交
            
            ***此時事務2讀取到的數據是保存在數據庫內存中的數據，稱爲髒讀。
            ***讀到的數據爲髒數據
            詳細解釋：
                髒讀就是指:當一個事務正在訪問數據，並且對數據進行了修改，而這種修改還沒有提交到數據庫中，這時，
                另外一個事務也訪問這個數據，然後使用了這個數據。因爲這個數據是還沒有提交的數據，那麼另外一個
                事務讀到的這個數據是髒數據，依據髒數據所做的操作可能是不正確的。
            
        不可重複讀：在同一事務中，兩次讀取同一數據，得到內容不同
            事務1：查詢一條記錄
                            -------------->事務2：更新事務1查詢的記錄
                            -------------->事務2：調用commit進行提交
            事務1：再次查詢上次的記錄
            
            ***此時事務1對同一數據查詢了兩次，可得到的內容不同，稱爲不可重複讀
            
        幻讀：同一事務中，用同樣的操作讀取兩次，得到的記錄數不相同
            事務1：查詢表中所有記錄
                              -------------->事務2：插入一條記錄
                              -------------->事務2：調用commit進行提交
            事務1：再次查詢表中所有記錄
            
            ***此時事務1兩次查詢到的記錄是不一樣的，稱爲幻讀
            詳細解釋：
                幻讀是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，
                這種修改涉及到表中的全部數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表
                中插入一行新數據。那麼，以後就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行，
                就好象發生了幻覺一樣。

處理以上隔離級別的問題，採用如下方是：

  事務隔離五種級別：
        TRANSACTION_NONE  不使用事務。
        TRANSACTION_READ_UNCOMMITTED  允許髒讀。
        TRANSACTION_READ_COMMITTED  防止髒讀，最常用的隔離級別,並且是大多數數據庫的默認隔離級別
        TRANSACTION_REPEATABLE_READ  可以防止髒讀和不可重複讀，
        TRANSACTION_SERIALIZABLE  可以防止髒讀，不可重複讀取和幻讀，（事務串行化）會降低數據庫的效率

  以上的五個事務隔離級別都是在Connection接口中定義的靜態常量，

  使用setTransactionIsolation(int level) 方法可以設置事務隔離級別。
        如:con.setTransactionIsolation(Connection.REPEATABLE_READ);

  注意：事務的隔離級別受到數據庫的限制，不同的數據庫支持的的隔離級別不一定相同

 

      1 髒讀：修改時加排他鎖，直到事務提交後才釋放，讀取時加共享鎖，讀取完釋放事務1讀取數據時加上共享鎖後（這 樣在事務1讀取數據的過程中，其他事務就不會修改該數據），不允許任何事物操作該數據，只能讀取，之後1如果有更新操作，那麼會轉換爲排他鎖，其他事務更 無權參與進來讀寫，這樣就防止了髒讀問題。

       但是當事務1讀取數據過程中，有可能其他事務也讀取了該數據，讀取完畢後共享鎖釋放，此時事務1修改數據，修改 完畢提交事務，其他事務再次讀取數據時候發現數據不一致，就會出現不可重複讀問題，所以這樣不能夠避免不可重複讀問題。

      2 不可重複讀：讀取數據時加共享鎖，寫數據時加排他鎖，都是事務提交才釋放鎖。讀取時候不允許其他事物修改該數據，不管數據在事務過程中讀取多少次，數據都是一致的，避免了不可重複讀問題
      3 幻讀問題：採用的是範圍鎖RangeS RangeS_S模式，鎖定檢索範圍爲只讀，這樣就避免了幻影讀問題，在這裏有個描述範圍鎖的文章

 

當執行不同的隔離級別時，可能會發生各種各樣不同的問題。下面對它們進行總結並舉例說明：

幻讀 ：幻讀發生在當兩個完全相同的查詢執行時，第二次查詢所返回的結果集跟第一個查詢不相同。

發生的情況：沒有範圍鎖。

例子：

事務1	事務2
SELECT * FROM users WHERE age BETWEEN 10 AND 30 ;
	INSERT INTO users VALUES (3 , 'Bob' , 27 ) ;
SELECT * FROM users  WHERE age BETWEEN 10 AND 30 ;

 

 如何避免：實行序列化隔離模式，在任何一個低級別的隔離中都可能會發生。

 

 

不可重複讀

在基於鎖的並行控制方法中，如果在執行select時不添加讀鎖，就會發生不可重複讀問題。

在多版本並行控制機制中，當一個遇到提交衝突的事務需要回退但卻被釋放時，會發生不可重複讀問題。

 

事務1	事務2
SELECT * FROM users WHERE id=1;
	UPDATE users SET age = 21 WHERE id = 1 ; COMMIT; /* in multiversion concurrency*/ control, or lock-based READ COMMITTED *
SELECT * FROM users  WHERE id = 1 ;
	COMMIT; /* lock-based REPEATABLE READ */

 

在上面這個例子中，事務2提交成功，它所做的修改已經可見。然而，事務1已經讀取了一個其它的值。在序列化和可重複讀的隔離級別中，數據庫管理系統會返回舊值，即在被事務2修改之前的值。在提交讀和未提交讀隔離級別下，可能會返回被更新的值，這就是“不可重複讀”。

 

有兩個策略可以防止這個問題的發生：

1. 推遲事務2的執行，直至事務1提交或者回退。這種策略在使用鎖時應用。

2. 而在多版本並行控制中，事務2可以被先提交。而事務1，繼續執行在舊版本的數據上。當事務1終於嘗試提交時，數據庫會檢驗它的結果是否和事務1、事務2順序執行時一樣。如果是，則事務1提交成功。如果不是，事務1會被回退。

 

髒讀

髒讀發生在一個事務A讀取了被另一個事務B修改，但是還未提交的數據。假如B回退，則事務A讀取的是無效的數據。這跟不可重複讀類似，但是第二個事務不需要執行提交。 

 

事務1	事務2
SELECT * FROM users WHERE id=1
	UPDATE users SET age=21 WHERE id=1;
SELECT * FROM users WHERE id=1;
	COMMIT; /* lock-based DIRTY READ */