1.通過FOR UPDATE進行排他
①記錄在修改之前先給它上鎖，即:使用SELECT語句將要修改的記錄取出來，並且在sql末加上“FOR UPDATE WAIT timeout時間”（SELECT ・・・ FOR UPDATE WAIT timeout時間）
見用戶A的操作過程：
當其他用戶想要修改這條記錄時，發現這條記錄被人上了鎖，程序就會報錯。
見用戶B操作過程：
2.通過“修改時間”進行的排他處理
①在點擊詳細取得被修改數據詳細內容時，取得該記錄在數據庫中的“修改時間”(或更新次數)，我們稱它爲“修改時間1”。
②在點擊確認進行正式修改時，再次從數據庫中取得要修改記錄的“修改時間”(或更新次數)，我們稱它爲“修改時間2”。
然後比較“修改時間1”和“修改時間2”：
如果2者相等，則進行正常的修改操作，並將系統的當前時間寫入該記錄的“修改時間”字段。
如果發現2者不相等，說明該記錄已經被他人修改了，程序就報錯。
3.其實上述兩種方法都有弊端，第一種方法的弊端是，如果一個用戶鎖定數據的時間比較長，那麼其它用戶將要等待很長時間；第二種方法的弊端是，如果兩個用戶“同時”更新數據的，那麼數據庫將無法判斷到底要更新哪一個用戶的請求。
比較好的做法是把兩種方法結合起來。
①在點擊詳細取得被修改數據詳細內容時，取得該記錄在數據庫中的“修改時間”，我們稱它爲“修改時間1”。
②在點擊確認進行正式修改時，再次從數據庫中取得要修改記錄的“修改時間”，我們稱它爲“修改時間2”。
然後比較“修改時間1”和“修改時間2”：
如果2者相等，則進行正常的修改操作，並將系統的當前時間寫入該記錄的“修改時間”字段。
記錄在修改之前先給它上鎖，即:使用SELECT語句將要修改的記錄取出來，並且在sql末加上“FOR UPDATE WAIT timeout時間” （SELECT ・・・ FOR UPDATE WAIT timeout時間）
對該條記錄進行修改。修改完成，開鎖。
如果發現2者不相等，說明該記錄已經被他人修改了，程序就報錯。
例子：以更新次數爲例
詳細畫面初期化時取得更新次數
select upcount from table where key=?
如結果6，放於頁面隱藏控件中
點提交按鈕在數據庫操作前，進行比較，並且鎖定數據
select upcount from table where key=? and upcount =6 for update wait 5
如果2者相等修改數據
update table set item=?, upcount=upcount+1 where key=? and upcount=6
commit;
4、在oracle10g 中可以用ORA_ROWSCN 函數代替“更新次數”，ORA_ROWSCN是根據系統最後更新時間來進行計算。這個ORA_ROWSCN。在默認情況下是採用數據塊爲單位的，也就是一個數據庫塊(block)上共享一個ORA_ROWSCN，當數據更新的時候，這個block快的ORA_ROWSCN就會自動更新。所以在默認情況下的話，有可能出現假衝突的情況。比如A，B，C，D四條數據都在一個block上，這個時候A數據更新了，ORA_ROWSCN也會更新，這個時候因爲ABCD四條數據存儲在一個block上，所以BCD的ORA_ROWSCN也更新過了，其實BCD三條數據並沒有更新過，這個就造成了假更新的情況出現。
利用Oracle 9i提供的ROWDEPENDENCIES建表關鍵字可以解決上面的問題。這個關鍵字在Oracle9i中是爲了增加行依賴性跟蹤特性的，支持推進複製。在Oracle10g中有可以用來做行級別的ORA_ROWSCN用了。用這個關鍵字建表以後，在每行會增加一個隱藏的COLUMN，所以每行會增加6個byte的開銷。
這樣做的好處是不用再增加一個額外的域，而是由Oracle的ORA_ROWSCN來維護數據，數據開銷不是很大，並且減少了出錯的可能。缺點就是要重新建表。
create table test(id number(10), ....) ROWDEPENDENCIES
修改前的 ORA_ROWSCN 的值
select id ,ORA_ROWSCN from test
修改數據
update test set name = name || to_char(id) where id = 1 ;
修改後的 ORA_ROWSCN 的值
select id ,ORA_ROWSCN from test
只有第一行的數據的 ORA_ROWSCN 改變了，其它行未改變。
