oracle有悲觀鎖也有樂觀鎖。
悲觀鎖比較安全一些，可以防止丟失更新，但是就是互相等待，影響效率。
一般會用樂觀鎖，即開始操作時，樂觀的認為資料不會被其他人更改，直到提交時才加鎖檢查。比如在操作的表上加一列，儲存個時間戳，提交時檢查是不是最新的。不過樂觀鎖失敗的可能性比較大。
樂觀鎖，大多是基於資料版本（ version ）記錄機制實現。
資料版本即為資料增加乙個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加乙個 「version」 欄位來實現。
讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。
對於上面修改使用者帳戶資訊的例子而言，假設資料庫中帳戶資訊表中有乙個version 字段，當前值為 1 ；而當前帳戶餘額字段（ balance ）為 $100 。
1 操作員 a 此時將其讀出（ version=1 ），並從其帳戶餘額中扣除 $50（ $100-$50 ）。
2 在操作員 a 操作的過程中，操作員 b 也讀入此使用者資訊（ version=1 ），並從其帳戶餘額中扣除 $20 （ $100-$20 ）。
3 操作員 a 完成了修改工作，將資料版本號加一（ version=2 ），連同帳戶扣除後餘額（ balance=$50 ），提交至資料庫更新，此時由於提交資料版本大於資料庫記錄當前版本，資料被更新，資料庫記錄 version 更新為 2 。
4 操作員 b 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交資料（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 b 提交的資料版本號為 2 ，資料庫記錄當前版本也為 2 ，不滿足 「 提交版本必須大於記錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 b 的提交被駁回。
這樣，就避免了操作員 b 用基於 version=1 的舊資料修改的結果覆蓋操作員 a 的操作結果的可能。
樂觀鎖機制避免了長事務中的資料庫加鎖開銷，大大提公升了大併發量下的系統整體效能表現。
補充一下
在樂觀鎖中，常用的實現方法有3種。
[1]第一種就是在資料取得的時候把整個資料都copy到應用中，在進行提交的時候比對當前資料庫中的資料和開始的時候更新前取得的資料。當發現兩個資料一模一樣以後，就表示沒有衝突可以提交，否則則是併發衝突，需要去用業務邏輯進行解決。
[2]第二種樂觀鎖的做法就是採用版本戳，就是我上邊說的那個[#13樓 ]
[3]第三種做法和第二種做法有點類似，就是也新增乙個table的column，不過這次這個column是採用timestamp型，儲存資料最後更新的時間。在oracle9i以後可以採用新的資料型別，也就是timestamp with time zone型別來做時間戳。這種timestamp的資料精度在oracle的時間型別中是最高的，精確到微秒(還沒與到納秒的級別)，一般來說，加上資料庫處理時間和人的思考動作時間，微秒級別是非常非常夠了，其實只要精確到毫秒甚至秒都應該沒有什麼問題。和剛才的版本戳類似，也是在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則ok，否則就是版本衝突。如果不想把**寫在程式中或者由於別的原因無法把**寫在現有的程式中，也可以把這個時間戳樂觀鎖邏輯寫在trigger或者儲存過程中。
oracle 悲觀鎖 樂觀鎖
為了得到最大的效能，一般資料庫都有併發機制，不過帶來的問題就是資料訪問的衝突。為了解決這個問題，大多數資料庫用的方法就是資料的鎖定。資料的鎖定分為兩種方法，第一種叫做悲觀鎖，第二種叫做樂觀鎖。什麼叫悲觀鎖呢，悲觀鎖顧名思義，就是對資料的衝突採取一種悲觀的態度，也就是說假設資料肯定會衝突，所以在資料開...
oracle 鎖 悲觀鎖與樂觀鎖
總結於ocl程式設計藝術 經常發生的錯誤錯誤 更新丟失，舊資料更新了最新的資料。解決問題的方法 在oracle中看好悲觀鎖 取決於oracle鎖開銷小，高併發 但在其他的資料庫已deprecated 悲觀鎖 在使用者有意執行更新等dml操作之前，就在行上加鎖for update nowait 悲觀鎖...
Oracle 悲觀鎖和樂觀鎖
悲觀鎖 如select for update 悲觀鎖大多數情況下依靠資料庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣 的開銷往往無法承受。樂觀鎖基於資料版本 version 機制實現 為資料增加乙個版本標識，在基於資料庫表的版本解決方案中...