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

簡介

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

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

問題陳述

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

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

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

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

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

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

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

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

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

基于 DB2 事務鎖的任何會話鎖定實現(xiàn)必須解決鎖沖突問題。事務鎖沖突可以導致事務回滾（sqlcode -911），或者導致不確定地等待鎖。如果沒有 SKIP LOCKED DATA 這樣的數(shù)據(jù)庫概念，這個問題是很難解決的。

解決方案的模式

作為一個解決方案，建議定義一個 DB2 表，其中包含資源標識符的列表，并在所有應用程序?qū)Y源的訪問中使用鎖定和解鎖協(xié)議。lock() 函數(shù)的實現(xiàn)在一個 SQL fetch 語句中使用 DB2 新功能 skipping locked data。這是該解決方案的關(guān)鍵。

為資源鎖定創(chuàng)建一個DB2表

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

清單1. 創(chuàng)建鎖表的SQL示例

CREATE TABLE LockTable(ResourceId CHAR(10));

INSERT INTO LockTable VALUES('INDEX 1');

INSERT INTO LockTable VALUES('INDEX 2');

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

使用鎖定/解鎖協(xié)議訪問資源

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

實現(xiàn) lock() 函數(shù)

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

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

2.等待子線程發(fā)出表示鎖請求處理完成的信號，這時結(jié)果已經(jīng)可用了。

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

調(diào)用 unlock() 或者

應用程序終止。

4.lock() 函數(shù)主線程從子線程獲得結(jié)果。如果授予了鎖，那么 lock() 函數(shù)返回調(diào)用者。否則子線程被終止。

清單2. 在子線程中實現(xiàn) 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;

}

實現(xiàn) unlock() 函數(shù)

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

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

CLOSE C1;

ROLLBACK WORK;

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

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

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

清單 4. 填充鎖表來控制同時訪問的最大應用程序數(shù)量的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’。

結(jié)束語

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