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内部好像行使了一个线程池。既然云云，那这种设法也只能作罢。
（编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
