併發事務的丟失更新及數據鎖機制

    在事務的隔離級別內容中，能夠瞭解到兩個不同的事務在併發的時候可能會發生數據的影響。細心的話可以發現事務隔離級別章節中，臟讀、不可重覆讀、幻讀三個問題都是由事務A對數據進行修改、增加，事務B總是在做讀操作。如果兩事務都在對數據進行修改則會導致另外的問題：丟失更新。這是本博文所要敘述的主題，同時引出併發事務對數據修改的解決方案：鎖機制。

1、丟失更新的定義及產生原因。

   丟失更新就是兩個不同的事務（或者Java程式線程）在某一時刻對同一數據進行讀取後，先後進行修改。導致第一次操作數據丟失。可以用圖表表示如下：

       假如原來t_customer表內id為10的行，是一條{id:10，name:"王五"，age:15} 的數據，經過事務A修改後變成{id:10，name:"張三"，age:15}。事務B提交後，該數據變成了{id:10，name:"李四"，age:20}。由事務A所執行的操作在事務B的提交後，數據被衝掉了。這個現象就叫做丟失更新。

     備註：事實上Mysql資料庫會在事務裡面預設添加寫鎖，上面的現象是沒法重現的。瞭解即可。丟失更新就是由併發修改數據造成的。如下圖所示：

2、如何避免丟失更新的發生。

　　2.1 避免丟失更新有兩種方法：

            (1) 不使用事務。[最不可能的方法]

            (2)使用資料庫鎖機制防止丟失更新 

　　2.2 資料庫的鎖

          解決丟失更新的方法有好幾個，先來瞭解下資料庫裡面的"鎖"。從資料庫功能上面來看，資料庫設計上分為兩種鎖：讀鎖(共用鎖)和寫鎖(排它鎖)。

            資料庫在設計這兩種鎖的時候，這兩種鎖間的關係如下：讀鎖與讀鎖可以共存，讀鎖與寫鎖互斥，寫鎖與寫鎖互斥。(這種設計跟Java線程鎖機制是一樣的)。

      使用資料庫添加讀鎖和寫鎖的方法很簡單 , 但需要註意的是鎖必須在事務內進行聲明。在事務外聲明的鎖將不具備效應。

      為表添加讀鎖的方法：select * from t_account lock in share mode; (讀鎖與他人共用讀操作，很容易導致死鎖。)

      為表添加寫鎖的方法：select * from t_account for update;

       在JDBC這塊，事務一般通過sql腳本去控制處理。因此可以在sql腳本處添加上鎖去進行控制。(後面會整理通過ORM框架：hibernate對事務進行控制)

　　2.3 通過資料庫的鎖機制解決丟失更新

       解決丟失更新，主要使用兩種方法：

             1. 使用排它鎖。經過上面基於資料庫鎖的介紹可知，丟失更新可以使用寫鎖(排它鎖)進行控制。因為排它鎖添加到某個表的時候，事務未經提交，其他的事務根本沒法獲取修改權，因此排它鎖可以用來控制丟失更新。需要說明的是有時候，當知道某一行會發生併發修改的時候，可以把鎖定的範圍縮小。例如使用select * from t_account t wheret.id='1' for update; 這樣能夠比較好地把控上鎖的粒度，這種基於行級上鎖的方法叫"行級鎖"。

　　　 2. 使用樂觀鎖。

           樂觀鎖的原理是：認為事務不一定會產生丟失更新，讓事務進行併發修改，不對事務進行鎖定。發現併發修改某行數據時，樂觀鎖拋出異常。讓用戶解決。可以通過給數據表添加自增的version欄位或時間戳timestamp。進行數據修改時，資料庫會檢測version欄位或者時間戳是否與原來的一致。若不一致，拋出異常。

       時間戳與version的判斷都一樣，時間戳記錄的是當前時間。提交前資料庫會校驗提交前的時間戳是否與當前的一致。若一致則更新時間戳。

      以上為本次對資料庫併發更新的總結，後面補充在ORM框架下如何上鎖。