• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            OTL建立連接時可能會遇到的一個bug

            來源:http://blog.superliufa.com/?q=node/352

              最近因為工作原因,從OCICPP改為用OTL做Oracle開發。初時挺詫異的,怎么只有.h沒有.cpp?看過才知道原來一個頭文件就全做完了。它是對OCI的一個封裝,可以用stream的方式去操作數據庫。用起來還是比較簡便,但是感覺封裝得多了點。雖然OCI那些函數也挺復雜的,但至少覺得一切都在自己掌握之中。OTL這么一封裝了之后,有一些實現細節就不得而知了,這就導致了今天發現的一個bug。

              根據OTL關于otl_connect的說明,其構造函數之一是可以直接用來連接數據庫的。雖然正兒八經做這個事情的是rlogon(db_string),但是對構造函數otl_connect(connect_str, ...)的說明是其等于otl_connect(void)再加上一個rlogon(connect_str)。所以,一般就這樣寫了:otl_connect* pdb = new otl_connect("..."); 然后把pdb存在自己的數據庫連接池中。如果連接失敗,那么會拋出一個otl_exception異常。
              可是,今天卻遇到意外。連接字符串中,tnsname寫對了,但用戶名/密碼沒對。于是測試的時候發現,多次連接之后,數據庫那邊內存爆掉了,ORACLE.EXE的線程數也多到瘋掉。別的客戶端全連接不上了,報ORA-00020錯誤。
              process數滿,這倒也在情理之中。可是看了看session,發現會話其實很少。猜測是什么東西沒有釋放掉,不是connect就是cursor。查了一下代碼,發現沒有什么大問題,connect都是連接池管理,不會無限多下去的。otl_stream也都是在棧中聲明,花括號之后就自動析構了,cursor也不應該是問題。郁悶中,發現正常的連接反而不會有泄漏發生,會泄漏的都是連接錯誤的時候。但是連tnsname都不對反而就不會了,估計是因為OCI那邊根本就無法建立一個連接,也就耗不了資源。這下定位到了,就是這個創建連接的代碼上有問題。

              這段創建連接的代碼是這樣寫的。注意其中捕捉異常的部分:

            try
            {
              otl_connect
            * pdb = NULL;
              pdb 
            = new otl_connect("");
            }

            catch(otl_exception& e)
            {
              ……
              
            if (NULL != pdb)
                delete pdb;
              pdb 
            = NULL;
            }

              可以看到,如果連接不成功時沒有生成對象,那么應該返回空指針,這樣delete指令也不會發生。如果有對象生成,那么在異常處理代碼中應該已經把這個對象給銷毀了,而對象占用的資源應該也已經釋放了。但事實就是不同,由于OTL在這個構造函數中封裝了實現細節,而顯然這個實現并不完美,于是有了泄漏。

              采用如下的代碼,便不存在這個問題了:

            try
            {
              otl_connect
            * pdb = NULL;
              pdb 
            = new otl_connect();
              pdb
            ->rlogon("");
            }

            catch(otl_exception& e)
            {
              ……
              
            if (NULL != pdb)
                delete pdb;
              pdb 
            = NULL;
            }

              根據OTL的說明,這兩種建立連接的方法應該沒有區別。不過現在才有點明白為什么OTL提供的范例代碼都采用后一種方法了。

              追進OTL的頭文件中去看,應該可以弄明白原委。不過為了完成任務,沒有那么多時間了,這個任務只好留到下次再說。大致估計了一下,應該是因為在new otl_connect(connect_str)的時候就拋了異常,于是代碼跳轉到了catch處,pdb根本沒得到對象指針的賦值,這樣新生成的對象就丟了。建議用OTL的各位,在棧中是無所謂啦,但如果要在堆中初始化一個連接,千萬不要圖省事想用構造函數直接一步到位哦!

            posted on 2008-06-13 00:09 楊粼波 閱讀(2201) 評論(2)  編輯 收藏 引用

            評論

            # re: OTL建立連接時可能會遇到的一個bug [未登錄] 2008-06-13 17:24 starofrainnight

            代碼有問題!

            try
            {
              otl_connect* pdb = NULL; // 此 pdb 變量在大括號範圍外不存在!
              pdb = new otl_connect("");
            }
            catch(.....)
            {
            ..... // 這裡對pdb進行操作,哪裡來的 pdb 變量?
            }

            代碼應該改為:

            otl_connect* pdb = NULL;
            try
            {
              pdb = new otl_connect("");
            }
            catch(.....)
            {
            ..... // 這裡對pdb進行操作
            }

            否則,根本不能通過語法校驗!或者博主用的是一個特殊版本的C++編譯器?
              回復  更多評論   

            # re: OTL建立連接時可能會遇到的一個bug 2008-06-18 10:22 superliufa

            筆誤,寫博的時候隨手寫的代碼上去。一開始并沒考慮寫try/catch括起來。多謝指出!  回復  更多評論   

            人妻无码久久一区二区三区免费 | 久久久精品波多野结衣| 久久r热这里有精品视频| 久久久青草久久久青草| 久久久WWW成人免费毛片| 亚洲国产精品久久久天堂| 男女久久久国产一区二区三区| 国内精品久久久久久久久电影网| 久久影院亚洲一区| 日本加勒比久久精品| 久久无码AV中文出轨人妻| 亚洲AV乱码久久精品蜜桃| 伊人久久综在合线亚洲2019| 亚洲欧美久久久久9999| 久久久久AV综合网成人| 久久精品中文字幕一区| 精品久久久久久成人AV| 久久久这里有精品中文字幕| 久久久无码精品亚洲日韩按摩| 久久久久国色AV免费观看| 狠狠干狠狠久久| 亚洲中文字幕无码久久2017| 久久国产热这里只有精品| 99久久无色码中文字幕| 久久无码中文字幕东京热| 久久精品无码一区二区三区日韩| 99久久无码一区人妻a黑| 久久久久久久精品妇女99| 久久夜色精品国产www| 国产精品va久久久久久久| 久久99精品久久久久久hb无码| 2019久久久高清456| 久久久久99精品成人片| 91久久福利国产成人精品| 99久久精品国产高清一区二区| 无码精品久久久天天影视| 婷婷五月深深久久精品| 国产成人精品综合久久久久| 伊人久久大香线蕉成人| 少妇无套内谢久久久久| 午夜人妻久久久久久久久|