Oracle中樂觀鎖定的四種實現方式：
- 更新前在應用中存儲所要操作行的“前映像”，更新時使用存儲的舊記錄來判斷當前值是否已經改變；
- 使用一個特殊的列，這個列由一個數據庫觸發器或應用程序代碼維護，可以告訴我們記錄的 “版本”；
- 使用一個校驗和或散列值，這是使用原來的數據計算得出的；
- 使用新增的 Oracle 10g 特性 ORA_ROWSCN 。
1.使用版本列
附加一個LAST_MODIFIED列，類型可以為 timestamp with time zone default systemstamp（ora 9i以上）,這個類型在Oracle中精度最高，精確到百萬分之一秒。
不建議使用觸發器，因為開銷太大，而由DML來負責。
2.使用校驗和的樂觀鎖定
使用一個虛擬的版本列來判斷數據是否改變。
與使用版本列的做法一樣，我們可以采用同樣的方法使用這些散列值或校驗和，只需把從數據庫讀出數據時得到的散列或校驗和值與修改數據前得到的散列或校驗和值進行比較。在我們讀出數據之后， 但是在修改數據之前，如果有人在這段時間內修改了這一行的值，散列值或校驗和值往往會大不相同。
以下為Oracle提供的三種計算散列值得數據包：
OWA_OPT_LOCK.CHECKSUM ：這個方法在 Oracle8i 8.1.5 及以上版本中提供。給定一個串，其中一個函數會返回一個 16 位的校驗和。給定 ROWID 時，另一個函數會計算該行的 16 位校驗和，而且同時將這一行鎖定。出現沖突的可能性是 65 536 分之一（ 65 536 個串中有一個沖突，這是假警報的最大幾率）。
DBMS_OBFUSCATION_TOOLKIT.MD5 ：這個方法在 Oracle8i 8.1.7 及以上版本中提供。它會計算一個 128 位的消息摘要。沖突的可能性是 3.4028E+38 分之一（非常小）。
DBMS_CRYPTO.HASH ：這個方法在 Oracle 10g Release 1 及以上版本中提供。它能計算一個SHA-1 （安全散列算法 1 ， Secure Hash Algorithm 1 ）或 MD4/MD5 消息摘要。建議你使用 SHA- 1算法。
注意 很多編程語言中都提供了一些散列和校驗和函數，所以還可以使用數據庫之外的散列和校驗和函數。
要記住，計算散列或校驗和是一個 CPU 密集型操作（相當占用 CPU ），其計算代價很昂貴。如果系統上 CPU 是稀有資源，在這種系統上就必須充分考慮到這一點。不過，如果從 “ 網絡友好性 ” 角度看，這種方法會比較好，因為只需在網絡上傳輸相當小的散列值，而不是行的完整的前映像和后映像（以便逐列地進行比較），所以消耗的資源會少得多。下面會使用一個新的 Oracle 10g 函數 ORA_ROWSCN ，它不僅很小（類似于散列），而且計算時不是 CPU 密集的（不會過多占用 CP U ）。
3.使用ORA_ROWSCN
ORA_ROWSCN 建立在內部 Oracle 系統時鐘（ SCN ）基礎上。在 Oracle 中，每次提交時， SCN 都會推進（其他情況也可能導致 SCN 推進，要注意， SCN 只會推進，絕對不會后退）。這個概念與前面在獲取數據 時得到 ORA_ROWSCN 的方法是一樣的，更新數據時要驗證 SCN 未修改過。之所以我會強調這一點（而不是草草帶過），原因是除非你創建表時支持在行級維ORA_ROWSCN ，否則 Oracle 會在塊級維護。也就是說，默認情況下，一個塊上的多行會共享相同的 ORA_ROWSCN 值。如果更新一個塊上的某一行，而且 這個塊上還有另外 50 行，那么這些行的 ORA_ROWSCN 也會推進。這往往會導致許多假警報，你認為某一行已經修改，但實際上它并沒有改動。因此，需要注意這一點，并了解如何改變這種行為。
要修改這個特性，只能重新建立表，并啟用 ROWDEPENDENCIES 。
使用樂觀鎖定還是悲觀鎖定？
那么哪種方法最好呢？根據我的經驗，悲觀鎖定在 Oracle 中工作得非常好（但是在其他數據庫中可能不是這樣），而且與樂觀鎖定相比，悲觀鎖定有很多優點。不過，它需要與數據庫有一條有狀態的連接，如客戶 / 服務器連接，因為無法跨連接持有鎖。正是因為這一點，在當前的許多情況下，悲觀鎖定不太現實。過去，客戶 / 服務器應用可能只有數十個或數百個用戶，對于這些應用，悲觀鎖定是我的不二選擇。不過，如今對大多數應用來說，我都建議采用樂觀并發控制。要在整個事務期間保持連接，這個代價太大了，一般無法承受。
在這些可用的方法中，我使用哪一種呢？我喜歡使用版本列方法，并增加一個時間戳列（而不只是一個 NUMBER ）。從長遠看，這樣能為我提供一個額外的信息： “ 這一行最后一次更新發生在什么時間？ ” 所以意義更大。而且與散列或校驗和方法相比，計算的代價不那么昂貴，在處理 LONG 、 LONG RAW 、 CLOB 、 BLO B和其他非常大的列時，散列或校驗和方法可能會遇到一些問題，而版本列方法則沒有這些問題。
如果必須向一個表增加樂觀并發控制，而此時還在利用悲觀鎖定機制使用這個表（例如，客戶 / 服務器應用都在訪問這個表，而且還在通過 Web 訪問），我則傾向于選擇 ORA_ROWSCN 方法。這是因為，在現有的遺留應用中，可能不希望出現一個新列，或者即使我們另外增加一步把這個額外的列隱藏起來（使用散列等等方式），為了維護這個列，可能需要一個必要的觸發器，而這個觸發器的開銷非常大，這是我們無法承受的。 ORA_ROWSCN技術沒有干擾性，而且在這個方面是輕量級的（當然，這是指我們執行表的重建之后）。
散列 / 校驗和方法在數據庫獨立性方面很不錯，特別是如果我們在數據庫之外計算散列或校驗和，則更是如此。不過，如果在中間層而不是在數據庫中執行計算，從 CPU 使用和網絡傳輸方面來看，就會帶來更大的資源使用開銷。