页面打开中,请稍候...
www.Gzu521.com
| GZU521.COM学习网 |
|
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 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内部似乎使用了一个线程池。既然如此，那这种想法也只能作罢。 标题叫 编写安全的sql server扩展存储过程，其实还是很不安全，除非调用者严格遵守 init与finalize的配对原则，幸运的是，这个是程序员可以控制的，只要遵守这个原则，那就是安全的。 |
责任编辑：gzu521
您现在的位置:
