編寫安全的SQL Server擴充預存程序

SQL Server 的擴充預存程序，其實就是一個普通的 Windows DLL,只不過按照某種規則實現了某些函數而已。
　　近日在寫一個擴充預存程序時，發現再寫這類動態庫時，還是有一些需要特別注意的地方。之所以會特別注意，是因為DLL運行於SQL Server的地址空間，而SQL Server到底是怎麼進行線程調度的，卻不是我們能瞭解的，即便瞭解也無法控制。
　　我們寫動態庫一般是自己用，即便給別人用，也很少像SQL Server這樣，一個動態庫很有可能載入多次，並且都是載入到一個進程的地址空間中。我們知道，當一個動態庫載入到進程的地址空間時，DLL所有全域與局部變數初始化且僅初始化一次，以後再次調用 LoadLibrary函數時，僅僅增加其引用計數而已，那麼很顯然，假如有一全域 int ,初始化為0，調用一個函數另其自加，此時其值為1,然後再調用LoadLibray,並利用返回的控制代碼調用輸出函數輸出該值，雖然調用者覺得自己載入後立即輸出，然後該值確實1而不是0。windows是進程獨立的，而線上程方面，假如不注意，上面的情況很可能會程式員帶來麻煩。
　　介紹一下我的擴充預存程序，該動態庫匯出了三個函數: Init,work,Final,Init讀檔案，儲存資訊於記憶體，work簡單的只是向該記憶體檢索資訊,Final回收記憶體。如上所說，假如不考慮同一進程空間多次載入問題，兩次調用Init將造成無謂的浪費，因為我第一次已經讀進了記憶體，要是通過堆分配記憶體，還會造成記憶體泄露。
　　我使用的引用計數解決的該問題，代碼很短，直接貼上來：
#include "stdafx.h"
#include <string>
using namespace std;
extern "C" {
RETCODE __declspec(dllexport) xp_part_init(SRV_PROC *srvproc);
RETCODE __declspec(dllexport) xp_part_process(SRV_PROC *srvproc);
RETCODE __declspec(dllexport) xp_part_finalize(SRV_PROC *srvproc);
}
#define XP_NOERROR 0
#define XP_ERROR 1
HINSTANCE hInst = NULL;
int nRef = 0;
void printError (SRV_PROC *pSrvProc, CHAR* szErrorMsg);
ULONG __GetXpVersion(){ return ODS_VERSION;}
SRVRETCODE xp_part_init(SRV_PROC* pSrvProc){
typedef bool (*Func)();
if(nRef == 0){
hInst = ::LoadLibrary("part.dll");
if(hInst == NULL){
printError(pSrvProc,"不能載入part.dll");
return XP_ERROR;
}
Func theFunc = (Func)::GetProcAddress(hInst,"Init");
if(!theFunc()){
::FreeLibrary(hInst);
printError(pSrvProc,"不能獲得分類號與專輯的對應表");
return XP_ERROR;
}
}
++ nRef;
return (XP_NOERROR);
}
SRVRETCODE xp_part_process(SRV_PROC* pSrvProc){
typedef bool (*Func)(char*);
if(nRef == 0){
printError(pSrvProc,"函數尚未初始化,請首先調用xp_part_init");
return XP_ERROR;
}
Func theFunc = (Func)::GetProcAddress(hInst,"Get");
BYTE bType;
ULONG cbMaxLen,cbActualLen;
BOOL fNull;
char szInput[256] = {0};
if (srv_paraminfo(pSrvProc, 1, &bType, (ULONG*)&cbMaxLen, (ULONG*)&cbActualLen, (BYTE*)szInput, &fNull) == FAIL){
printError(pSrvProc,"srv_paraminfo 返回 FAIL");
return XP_ERROR;
}
szInput[cbActualLen] = 0;
string strInput = szInput;
string strOutput = ";";
int cur,old = 0;
while(string::npos != (cur = strInput.find(’;’,old)) ){
strncpy(szInput,strInput.c_str() + old,cur - old);
szInput[cur - old] = 0;
old = cur + 1;
theFunc(szInput);
if(string::npos ==strOutput.find((string)";" + szInput))
strOutput += szInput;
}
strcpy(szInput,strOutput.c_str());
if (FAIL == srv_paramsetoutput(pSrvProc, 1, (BYTE*)(szInput + 1), strlen(szInput) - 1,FALSE)){
printError (pSrvProc, "srv_paramsetoutput 調用失敗");
return XP_ERROR;
}
srv_senddone(pSrvProc, (SRV_DONE_COUNT | SRV_DONE_MORE), 0, 0);
return XP_NOERROR;
}
SRVRETCODE xp_part_finalize(SRV_PROC* pSrvProc){
typedef void (*Func)();
if(nRef == 0)
return XP_NOERROR;
Func theFunc = (Func)::GetProcAddress(hInst,"Fin");
if((--nRef) == 0){
theFunc();
::FreeLibrary(hInst);
hInst = NULL;
}
return (XP_NOERROR);
}
　　我想雖然看上去不是很高明，然而問題應該是解決了的。
　　還有一點說明，為什麼不使用Tls，老實說，我考慮過使用的，因為其實代碼是有一點問題的，假如一個使用者調用xp_part_init,然後另一個使用者也調用xp_part_init，注意我們的預存程序可是伺服器端的，然後第一個使用者調用xp_part_finalize，那麼會怎樣，他仍然可以正常使用xp_part_process，這倒無所謂，然而第一個使用者調用兩次xp_part_finalize，就能夠影響第二個使用者了，他的xp_part_process將返回錯誤。
　　使用Tls 似乎可以解決這問題，例如再添加一個tls_index變數，調用 TlsSetValue儲存使用者私人資料，TlsGetValue檢索私人資料，當xp_part_init時，假如該私人資料為0，執行正常的初始化過程，（即上面的xp_part_init）執行成功後儲存私人資料為1，假如是1，直接返回，xp_part_finalize時，假如私人資料為1，則執行正常的xp_part_finalize，然後設私人資料為0，假如是0，直接返回。
　　好像想法還是不錯的，這樣隔離了多個使用者，安全性似乎提高了不少，然而事實是不可行的。因為Tls儲存的並不是私人資料，而是執行緒區域變數，我們不能保證一個使用者的多次操作都是用同一個線程執行的，這個由SQL Server自己控制，事實上我在查詢分析器裡多次執行的結果顯示，SQL Server內部似乎使用了一個線程池。既然如此，那這種想法也只能作罷。