B/S構(gòu)架的應用越來越普及，但由于它有別于C/S構(gòu)架的特殊性，并發(fā)控制始終沒能得到很好的解決，如售票系統(tǒng)經(jīng)常會出現(xiàn)同一張火車票出售多次的現(xiàn)象。典型的案例如下：
例如若有兩個客戶端，A客戶先讀取了賬戶余額2000元，之后B客戶也讀取了賬戶余額2000元的數(shù)據(jù)，A客戶提取了500元，對數(shù)據(jù)庫作了變更，此時數(shù)據(jù)庫中的余額為1500元，B客戶也要提取1300元，根據(jù)其所取得的資料，2000-1300將為700余額，若此時再對數(shù)據(jù)庫進行變更，最后的余額700元就會不正確，應當是200元，問題的出現(xiàn)是由于兩個客戶對同一條數(shù)據(jù)進行并發(fā)訪問造成的。
Web應用中并發(fā)控制的特殊性
上述問題在C/S構(gòu)架中可以通過長事務來實現(xiàn)，但Web應用是基于Internet網(wǎng)絡環(huán)境的，其中的并發(fā)控制有其內(nèi)在的特殊性：
1. Web所基于的網(wǎng)絡協(xié)議HTTP(Hyper Text Transfer Protocol)是一種無連接的協(xié)議，數(shù)據(jù)庫服務器無法保存事務的狀態(tài)信息；
2. 用戶可以隨時中止或啟動瀏覽器中當前主頁上的事務。
由于上述特殊性，Web應用中并發(fā)控制不能采用嚴格的長事務來實現(xiàn)，但可以長事務的思路來實現(xiàn)，在數(shù)據(jù)讀取的時候把相應的數(shù)據(jù)鎖定，在更新階段把鎖放開，然后更新數(shù)據(jù)。
Web應用中并發(fā)控制的實現(xiàn)
業(yè)務邏輯的實現(xiàn)過程中，往往需要保證數(shù)據(jù)訪問的排他性。如在 金融 系統(tǒng)的日終結(jié)算處理中，我們希望針對某個cut-off時間點的數(shù)據(jù)進行處理，而不希望在結(jié)算進行過程中（可能是幾秒種，也可能是幾個小時），數(shù)據(jù)再發(fā)生變化。此時，我們就需要通過一些機制來保證這些數(shù)據(jù)在某個操作過程中不會被外界修改，這樣的機制，就是所謂的“鎖”，即給選定的目標數(shù)據(jù)上鎖，使其無法被其他程序修改。有兩種鎖機制：即通常所說的“樂觀鎖(Optimistic Locking)” 和“悲觀鎖(Pessimistic Locking)”。
1．樂觀鎖(Optimistic Locking)
樂觀鎖(optimistic locking)則樂觀的認為資料的存取很少發(fā)生同時存取的問題，因而不作數(shù)據(jù)庫層次上的鎖定，為了維護正確的數(shù)據(jù)，樂觀鎖定使用應用程序上的邏輯實現(xiàn)版本控制來解決。
并發(fā)控制時，數(shù)據(jù)不一致的情況一旦發(fā)生，有幾個解決的 方法 ，一種是先更新為主，一種是后更新的為主，比較復雜的就是檢查發(fā)生變動的數(shù)據(jù)來實現(xiàn)，或是檢查所有屬性來實現(xiàn)樂觀鎖定。
Hibernate通過版本號檢查來實現(xiàn)后更新為主，這也是Hibernate所推薦的方式，在數(shù)據(jù)庫中加入一個VERSON欄記錄，在讀取數(shù)據(jù)時連同版本號一同讀取，并在更新數(shù)據(jù)時遞增版本號，然后比對版本號與數(shù)據(jù)庫中的版本號，如果大于數(shù)據(jù)庫中的版本號則予以更新，否則就回報錯誤。
以Hibernate實現(xiàn)版本號控制鎖定的話，我們的對象中增加一個version屬性，例如：
public class MyAccount {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return version;
}
....
}
|
而在映像文件中，我們使用optimistic-lock屬性設定version控制，屬性欄之后增加一個標簽，例如：
optimistic-lock="version"
|
設定好版本控制之后，在上例中如果B客戶試圖更新數(shù)據(jù)，將會引發(fā)StableObjectStateException例外，我們可以捕捉這個例外，在處理中重新讀取數(shù)據(jù)庫中的數(shù)據(jù)，同時將B客戶目前的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)讀出來，讓B客戶有機會比對不一致的數(shù)據(jù)，以決定要變更的部份，或者您可以設計程式自動讀取新的資料，并重復扣款業(yè)務流程，直到數(shù)據(jù)可以更新為止，這一切可以在后臺執(zhí)行，而不用讓您的客戶知道。在其它架構(gòu)中也可通過這種思路來實現(xiàn)樂觀鎖，但版本控制和沖突的檢測要在自己程序的程序中實現(xiàn)和維護。
2．悲觀鎖(Pessimistic Locking)
雖然樂觀鎖能夠提高系統(tǒng)的性能，但它是對發(fā)生沖突的訪問進行事后的補救，應用在用戶輸入數(shù)據(jù)量很少的場合比較適合，但如果在 企業(yè) ERP，用戶與系統(tǒng)交互涉及大量數(shù)據(jù)在頁面表單上錄入，如果事后提交失敗后才提示用戶要重新錄入是很不現(xiàn)實的，所以有必要進行事前控制，這就要采用悲觀鎖。
在多個客戶端可能讀取同一筆數(shù)據(jù)或同時更新一筆數(shù)據(jù)的情況下，防止同一個數(shù)據(jù)被修改而造成混亂，最簡單的手段就是在讀取時對數(shù)據(jù)進行鎖定，其它客戶端不能對同一筆數(shù)據(jù)進行更新的讀取動作。
悲觀鎖定（Pessimistic Locking）一如其名稱所示，悲觀的認定每次資料存取時，其它的客戶端也會存取同一筆數(shù)據(jù)，因此對該筆數(shù)據(jù)進行事先鎖定，直到自己操作完成后解除鎖定。
悲觀鎖定通常透過系統(tǒng)或數(shù)據(jù)庫本身的功能來實現(xiàn)，依賴系統(tǒng)或數(shù)據(jù)庫本身提供的鎖定機制，Hibernate即是如此，我們可以利用Query或Criteria的setLockMode()方法來設定要鎖定的表或列（row）及其鎖定模式，鎖定模式有以下的幾個：
LockMode.WRITE：在insert或update時進行鎖定，Hibernate會在save()方法時自動獲得鎖定。
LockMode.UPGRADE：利用SELECT … FOR UPDATE進行鎖定。
LockMode.UPGRADE_NOWAIT：利用SELECT … FOR UPDATE NOWAIT進行鎖定，在Oracle環(huán)境下使用。
LockMode.READ：在讀取記錄時Hibernate會自動獲得鎖定。
LockMode.NONE：沒有鎖定。
也可以在使用Session的load()或是lock()時指定鎖定模式以進行鎖定。
如果數(shù)據(jù)庫不支持所指定的鎖定模式，Hibernate會選擇一個合適的鎖定替換，而不是丟出一個例外。
3．其它構(gòu)架中悲觀鎖的實現(xiàn)
Hibernate的悲觀鎖，也是基于數(shù)據(jù)庫的鎖機制實現(xiàn)。下面的代碼實現(xiàn)了對“用戶”查詢記錄的加鎖：
String sqlStr = "from userInfo as user where user.userId=’admin’";
Query query = session.createQuery(sqlStr);
query.setLockMode("user",LockMode.UPGRADE); //加鎖
List userList = query.list();//執(zhí)行查詢，獲取數(shù)據(jù)
|
query.setLockMode對查詢語句中，特定別名所對應的記錄進行加鎖（我們?yōu)閡serInfo類指定了一個別名“user”），這里也就是對返回的所有user記錄進行加鎖：
select tuser0_.id as id, tuser0_.userId as userId, tuser0_.group_id as group_id,
tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where
(tuser0_.userId =’admin’ ) for update
|
通過上述轉(zhuǎn)換后的sql語句可知，Hibernate的加鎖其實是利用了數(shù)據(jù)庫的for update語句，在讀取階段對某條記錄的鎖定，而在更新階段提交，釋放鎖。
其實其它架構(gòu)也可以采取該思路，不過，數(shù)據(jù)庫的for update語句的鎖定和釋放一定要在數(shù)據(jù)的同一個連接中，如果讀取階段和更新階段不是統(tǒng)一連接，即讀取之后斷開了與數(shù)據(jù)庫的連接，則for update語句的鎖定立即失效，為此，如果其它架構(gòu)中要采取這種方式則要做相應的調(diào)整。
首先，由于Web應用是無狀態(tài)的，也就是說數(shù)據(jù)庫的for update語句的鎖定和釋放不一定是數(shù)據(jù)的同一個連接，為此，采用痕跡跟蹤法，在讀取數(shù)據(jù)時生成唯一的序列號(serialId)，建立與數(shù)據(jù)連接的映射，并放置一個map數(shù)據(jù)結(jié)構(gòu)中；在更新時，通過該serialId在連接池中重新獲取該連接，用該連接去更新數(shù)據(jù)。
如果系統(tǒng)是采用dao讀取數(shù)據(jù)，實體bean去更新數(shù)據(jù)，則只要在更新數(shù)據(jù)之前斷開讀取數(shù)據(jù)時的連接，則可以通過其它途徑更新數(shù)據(jù)，如下代碼所示：
public void update (AbstractEntityData data, String[] selTeamName ,String serialId)
throws Exception {
dao.closeConnect(serialId);
bo.update(data);
}
|
其中，dao.closeConnect(serialId)是斷開數(shù)據(jù)連接，bo.update(data)是通過EJB更新數(shù)據(jù)庫
4．序列號(serialId)的創(chuàng)建和維護
由于不同用戶可能同時建立連接或同一用戶先后建立連接，故創(chuàng)建序列號可以在讀取數(shù)據(jù)時通過sessionId和時間戳組合而成。而在操作的過程中，為了保持序列號不會丟失和唯一性，它不能放在session或application中，而是放在頁面的request對象里，通過它向其它頁面?zhèn)鬟f。
5．關聯(lián)表的鎖定
其實，Hibernate的悲觀鎖方式只能對單個表的記錄進行鎖定，但現(xiàn)實中，存在關聯(lián)更新的情況，即在更新主表的時候有可能會更新到與之相關的子表，與此同時，其它用戶也可能通過其它主表更新相應的子表同一條記錄。
有兩種方式處理，一是在讀取數(shù)據(jù)通過sql語句關聯(lián)子表相應記錄，因為for update對所有關聯(lián)表中符合條件的記錄都會加鎖；二是為子表找一個入口表，在更新子表的同時，必須更新子表的入口表。
6．例外操作的處理
采用這種方式，有一些例外情況必須小心處理，一是頁面的關閉，如果調(diào)用相應的方法，如onbeforeunload()等，釋放對應的數(shù)據(jù)庫連接；二是用戶非正常關機退出系統(tǒng)，必須有數(shù)據(jù)庫周期清除無用的連接，如間隔二十分鐘等，來釋放讀取時對數(shù)據(jù)的鎖定，否則，該數(shù)據(jù)會長時間被鎖定，直至應用服務器重啟。
結(jié)論
軟件系統(tǒng)的并發(fā)控制一般是通過加鎖來實現(xiàn)，同樣，Web應用也是采用樂觀鎖和悲觀鎖來實現(xiàn)，樂觀鎖是一種事后補救措施，是通過程序的邏輯控制版本來實現(xiàn)的，而悲觀鎖是事前的一種預防措施，它利用數(shù)據(jù)庫的鎖機制來實現(xiàn)，Hibernate對它做了一層封裝，使應用更加方便，為了讓其它架構(gòu)都能適用，本文還原了Hibernate的實現(xiàn)原理，提出一般的實現(xiàn)思路和注意實現(xiàn)。