面對web並發訪問時候，可能會產生這樣的問題，你是怎麼設計的？

一般的web application，可能會遇到這樣的問題，你可以這樣類比：用瀏覽器開一個視窗，選中一條記錄，編輯之，但是先不要儲存，新開一個瀏覽器視窗，找到這條記錄，刪除之，然後再回到第一個視窗點擊儲存按鈕。

假如程式沒有做特別的處理，肯定會報錯。

這個問題，有些公司並不考慮這樣的問題，認為這個發生的機率很低，報錯就報錯吧，反正機率很低。 

是這樣的，假如是一般的小的系統，訪問人數和並發數不是很多的時候，基本上不太用考慮。但是一個大的，比如說海關，銀行，或者線上電子商務網站，基於系統健壯性考慮，你不得不考慮。。。

目前一個通用的做法有兩種：

鎖機制：1.悲觀鎖；2.樂觀鎖。

在web程式裡，基本上不能考慮悲觀鎖（會使得系統的產生不可估量額效能損失，也失去了web 的意義了。）

當然在web程式裡只能樂觀鎖，一個通用的做法就是每張表裡設定一個欄位version_no，每次刪除或者修改的時候，去資料庫比較一下，資料庫的version_no還變化了，假如不等了，就說明在你之前發生過了變化了，這次修改或者刪除動作不能成功。。。

我們在做系統的時候，由於系統初期沒有考慮到，到了後來使用者測試的時候，出現了這樣的問題，我們就是在我們的basicDao裡做了一次檢查，如果不對勁就throw一個exception，在basicDao裡使用了模版技巧用來保證dao和service層不用改變方法的申明，保證了這個改變影響的代碼降到了最低。

但是這裡有一個問題，假如是使用hibernate3技術，假如你update的時候，由於特殊的情況，你得使用merge（bo）方法－－－否則你會遇到a different Object with same indicator in a session，那樣就會帶來一個新的問題，假如你不做一點處理，hibernate發現你的這條記錄已經刪除了，他會automagiclly create一條新的記錄到資料庫裡。