Pessimistic and Optimistic locking

事務隔離一般經過鎖定任何對事務中資源的訪問來實現的。總的來講，有兩種方法針對事務的鎖定：樂觀鎖(Pessimistic locking)和悲觀鎖(Optimistic locking)

悲觀鎖（Pessimistic locking）

悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其餘事務，以及來自外部系統的事務處理）修改持保守態度，所以，在整個數據處理過程當中，將數據處於鎖定狀態。悲觀鎖的實現，每每依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，不然，即便在本系統中實現了加鎖機制，也沒法保證外部系統不會修改數據）。

悲觀鎖的缺點在於，資源第一次的訪問就會被事務鎖定，除非事務完成，資源始終是不可訪問的。若是大量事務都是僅僅對事務進行檢索而不是更新操做，那麼這種排它鎖會大量阻塞，引發鎖的爭用。這種狀況下，樂觀鎖會是一種更好的方案。在使用悲觀鎖的狀況下，是經過請求失敗來保證併發安全性的。以銀行系統爲例，一旦一個帳戶經過事務來訪問，那麼就會鎖定整個帳戶。其餘的事務嘗試訪問帳戶都會被延遲，阻塞，直到以前的事務結束（完成或者回滾）。悲觀鎖會一直存在，直到事務提交或者回滾。

樂觀鎖（ Optimistic Locking ）

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認爲數據通常狀況下不會形成衝突，因此在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，若是發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去作。那麼咱們如何實現樂觀鎖呢，通常來講有如下2種方式：

• 使用數據版本（Version）記錄機制實現，這是樂觀鎖最經常使用的一種實現方式。何謂數據版本？即爲數據增長一個版本標識，通常是經過爲數據庫表增長一個數字類型的 「version」 字段來實現。當讀取數據時，將version字段的值一同讀出，數據每更新一次，對此version值加一。當咱們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的version值進行比對，若是數據庫表當前版本號與第一次取出來的version值相等，則予以更新，不然認爲是過時數據。
• 樂觀鎖定的第二種實現方式和第一種差很少，一樣是在須要樂觀鎖控制的table中增長一個字段，名稱無所謂，字段類型使用時間戳（timestamp）, 和上面的version相似，也是在更新提交的時候檢查當前數據庫中數據的時間戳和本身更新前取到的時間戳進行對比，若是一致則OK，不然就是版本衝突。

在使用樂觀鎖的時候，資源並不會在第一次由事務訪問的時候就鎖定，相反，資源的狀態會使用悲觀鎖的方式鎖定。當其餘事務併發的訪問資源，而且訪問資源的時候，是可能出現衝突的。當提交的時候，資源將要持久化到存儲的時候，會從新讀取資源的狀態，而後對比事務第一次訪問的時候所鎖定的狀態，若是兩個狀態不一樣，就會有衝突，從而事務會回滾。

一樣以銀行應用爲例，帳戶第一次由事務訪問的時候，就記錄了帳戶的餘額。當事務修改了帳戶的餘額的時候，帳戶的信息會在執行更新以前再次查詢帳戶的餘額。若是餘額在事務期間有變化，那麼事務就會失敗，若是餘額沒有變化，那麼此次修改就會被持久化到存儲中。

樂觀併發控制(Optimistic concurrency control)

樂觀併發控制（OCC）是一種應用到事務系統中的併發控制方法，好比在關係數據庫管理系統以及軟件事務內存等。OCC的理論依據是多數事務在執行更新的時候，是不會影響到彼此的。在運行時，事務使用資源是不須要獲取資源的鎖的，可是在提交以前，每一個事務都會驗證並無其餘的事務在修改數據。若是檢查碰到了更新衝突，那麼事務的提交會回滾，而後從新執行。

前面提到了OCC的理論依據，因此OCC通常用於低數據衝突的環境。當爭用不多的時候，事務就可以幾乎不須要付出管理鎖的代價，也不須要等待其餘事務完成了。這樣能夠比其它併發控制帶來更高的吞吐。固然了，若是數據資源頻繁出現爭用的話，那麼事務的重啓就會嚴重的影響性能了。這個時候使用其餘併發控制可能更好。然而，基於鎖的方法(悲觀鎖)在鎖定數據的時候，會嚴重限制併發性能。