如何用DB2 V9.1for z/OS來實現應用程序會話鎖定？

以下的文章主要描述的是正確運用DB2 V9.1for z/OS來實現應用程序會話鎖定的實際操作步驟，你如果對DB2 V9.1for z/OS來實現應用程序會話鎖定的實際操作步驟有興趣的話你就可以點擊以下的文章進行觀看了。

應用程序, 會話

DB2 for z/OS V9.1 的一項新特性 SKIP LOCKED DATA 使用戶能夠實現應用程序級別的會話鎖定，允許在中途進行 DB2 提交。通過本文介紹的簡便設計模式，熟悉這個特性的細節。

簡介

對於獲得最佳的應用程序性能，以及確保數據完整性和一致的應用程序行為來說，數據庫鎖定策略是非常重要的。在 Paul Ilechko 的文章 “Locking strategies for database Access”developerWorks，2006 年 3 月）中，他描述了進行數據庫鎖定的邏輯會話鎖定方式。除了事務鎖定之外，這種方式可以在更高的級別上控制應用程序的並發性。

很難實現消極會話鎖定方式的 bullet-proof 實現。但是，利用 DB2 Version 9.1 for z/OS 中引入的新特性 SKIP LOCKED DATA這個特性最初是為另一個完全不同的用途設計的，即避免鎖定），可以DB2 V9.1for z/OS實現一種簡單可靠的解決方案。

問題陳述

在許多場景中，應用程序級別上的並發性控制是必要的，例如：

確保在一組不可共享的資源上工作的應用程序互斥。一個真實的示例是，一個存儲過程使 DB2 外部的全文索引與 DB2 中存儲的數據同步。在這裡，受控制的資源是全文索引。它由索引名稱標識，索引名稱是存儲過程的一個參數。只有在索引名稱參數不同的情況下，才允許並行調用這個存儲過程。

控制同時對一個資源集進行操作的應用程序的最大數量。

對於消極會話鎖定，按照慣例，應用程序需要兩個函數 lock(resource) 和 unlock()。

下面是對解決方案的一些需求，這些需求使解決方案在應用程序級別難以實現：

1.解決方案必須為在應用程序之間可見的每個資源提供一個概念性的會話鎖。

2.即使持有會話鎖的應用程序非正常終止，解決方案也必須保證會話鎖被釋放。

3.鎖定或解鎖機制必須獨立於應用程序中的 DB2 事務也就是說，中途事務提交不能產生釋放會話鎖的副作用）。

4.解決方案必須避免會話鎖超時和長時間等待鎖。lock() 函數必須立即進行檢查並返回非阻塞方式）。

基於 DB2 事務鎖的任何會話鎖定DB2 V9.1for z/OS實現必須解決鎖沖突問題。事務鎖沖突可以導致事務回滾sqlcode -911），或者導致不確定地等待鎖。如果沒有 SKIP LOCKED DATA 這樣的數據庫概念，這個問題是很難解決的。

解決方案的模式

作為一個解決方案，建議定義一個 DB2 表，其中包含資源標識符的列表，並在所有應用程序對資源的訪問中使用鎖定和解鎖協議。lock() 函數的實現在一個 SQL fetch 語句中使用 DB2 新功能 skipping locked data。這是該解決方案的關鍵。

為資源鎖定創建一個DB2表

創建一個 DB2 表在下文中稱為 鎖表lock table）），它定義與會話鎖定相關的資源。假設邏輯會話鎖的范圍是某種資源標識符。在上面的全文索引示例中，這個標識符是索引名稱。對於每個資源，在這個表中插入一行。

清單1. 創建鎖表的SQL示例

CREATE TABLE LockTable(ResourceId CHAR(10));  
INSERT INTO LockTable VALUES('INDEX 1');  
INSERT INTO LockTable VALUES('INDEX 2');  

上面的示例演示如何在鎖表中填充兩個全文索引資源。每個索引不能由一個以上的應用程序使用。這意味著，應用程序 1 可能使用索引 1，同時應用程序 2 使用索引 2，但是不允許兩個應用程序中同時使用索引1。

使用鎖定/解鎖協議訪問資源

引入一個由兩個函數 lock(ResourceId) 和 unlock() 組成的協議，所有應用程序都需要遵守這個協議。具體的接口依賴於實現語言，在這裡無關緊要。關鍵的一點是，所有應用程序在訪問會話鎖控制的資源 之前，必須調用 lock(resourceId)。當不再需要這個資源時，它們應該調用 unlock()。

實現 lock() 函數

lock() 函數的實現必須確保調用者能夠立即得到請求的結果授予鎖還是不授予鎖）。另外，授予的鎖必須不受應用程序中 DB2 事務的影響。因此，lock() 的實現必須在一個單獨的線程中打開額外的 DB2 連接。所以，lock() 函數的DB2 V9.1for z/OS實現由以下步驟組成：

1.啟動一個對鎖請求進行處理的子線程。

2.等待子線程發出表示鎖請求處理完成的信號，這時結果已經可用了。

3.在子線程中，打開新的 DB2 連接，在鎖表中獲取具有所請求的資源 ID 的一行。在這裡，使用 SKIP LOCKED DATA 特性只獲得未被 DB2 鎖定的行例如，如果另一個應用程序持有這個資源上的會話鎖，就不能獲得這一行）。DB2 並不在獲取操作中等待。見 清單 2 中的示例代碼。現在，請求的結果必須在主線程中可用。子線程等待主線程的終止信號。如果授予了會話鎖，它就持有鎖表中一行上的 DB2 更新鎖，直到發生以下情況為止：

調用 unlock() 或者

應用程序終止。

4.lock() 函數主線程從子線程獲得結果。如果授予了鎖，那麼 lock() 函數返回調用者。否則子線程被終止。

清單2. 在子線程中DB2 V9.1for z/OS實現 lock() 的SQL代碼

DECLARE C1 CURSOR FOR  
SELECT ResourceId FROM LockTable WHERE ResourceId=:resourceId  
FOR UPDATE WITH CS SKIP LOCKED DATA;  
OPEN C1;  
FETCH C1;  
if (sqlca.sqlcode==NO_DATA_FOUND) {  
result=indexAlreadyLocked;  
} else {  
result=lockGranted;  
}  

實現 unlock() 函數

提供一個 unlock() 函數，它將終止仍然持有鎖表中某一行的 DB2 更新鎖的子線程。子線程中的終止代碼關閉 SQL 游標，並使事務回滾，見 清單 3。因此，會釋放這一行的 DB2 更新鎖，清單 2 中的下一個 SQL select 語句會看到這一行。

清單3. 在子線程中實現 unlock()的SQL代碼

CLOSE C1;  
ROLLBACK WORK;  

控制同時訪問一個資源的應用程序數量

對以上方式做一項簡單的修改，就可以控制同時訪問一個資源集的應用程序數量：

如果鎖表中有重復的行,就可以對資源進行並發使用。鎖表中一個資源的行數決定了可以同時訪問這個資源的最大應用程序數量。

清單 4. 填充鎖表來控制同時訪問的最大應用程序數量的SQL示例

INSERT INTO LockTable VALUES('INDEX 1');  
INSERT INTO LockTable VALUES('INDEX 1');  
INSERT INTO LockTable VALUES('INDEX 2');  
INSERT INTO LockTable VALUES('INDEX 2');  
INSERT INTO LockTable VALUES('INDEX 2');  

按照這段代碼，最多有兩個應用程序可以同時訪問 ‘INDEX 1’，最多有三個應用程序可以同時訪問 ‘INDEX 2’。

結束語

有一種簡單可靠的解決方案模式可用於在應用程序級別DB2 V9.1for z/OS實現會話鎖。它依賴於 DB2 Version 9.1 for z/OS 中的新特性 SKIP LOCKED DATA，且已成功應用於一個 DB2 開發項目。