<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    隨筆-35  評論-33  文章-0  trackbacks-0

          已經一個多月沒有寫東西了,不過最近確實很忙。前兩天在線上碰到一個C3P0的鏈接死鎖的異常,話說這個上古神物 ,我已經是很久不碰了。先貼異常



    異常截圖

    "apparent deadlocks":名詞解釋是說c3p0拿到鏈接之后,最終使用之后沒有返回到pool,導致死鏈檢測失敗。經過在stack Overflow檢索,https://stackoverflow.com/questions/3730844/c3p0-apparent-deadlock-when-the-threads-are-all-empty.發現增加一個statementCacheNumDeferredCloseThreads該參數的定義,就可以避免這個問題。

    經過查看官方文檔:http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads



    解釋:如果把該值設為超過1,statement的緩存就會自動跟蹤當前可用的connections,如果沒有再用,就會自動銷毀掉。如果需要另外的線程來專門銷毀緩存的statement,則還需要設置maxStatements與maxStatementsPerConnection。

    再貼一個官方的說明:

    Configuring Statement Pooling

    c3p0 implements transparent PreparedStatement pooling as defined by the JDBC spec. Under some circumstances, statement pooling can dramatically improve application performance. Under other circumstances, the overhead of statement pooling can slightly harm performance. Whether and how much statement pooling will help depends on how much parsing, planning, and optimizing of queries your databases does when the statements are prepared. Databases (and JDBC drivers) vary widely in this respect. It's a good idea to benchmark your application with and without statement pooling to see if and how much it helps.

    You configure statement pooling in c3p0 via the following configuration parameters:

    maxStatements

    maxStatementsPerConnection

    statementCacheNumDeferredCloseThreads

    maxStatementsis JDBC's standard parameter for controlling statement pooling.maxStatementsdefines the total numberPreparedStatementsa DataSource will cache. The pool will destroy the least-recently-used PreparedStatement when it hits this limit. This sounds simple, but it's actually a strange approach, because cached statements conceptually belong to individual Connections; they are not global resources. To figure out a size formaxStatementsthat does not "churn" cached statements, you need to consider the number offrequently usedPreparedStatements in your application,and multiply that by the number of Connections you expect in the pool (maxPoolSizein a busy application).

    maxStatementsPerConnectionis a non-standard configuration parameter that makes a bit more sense conceptually. It defines how many statements each pooled Connection is allowed to own. You can set this to a bit more than the number ofPreparedStatementsyour applicationfrequentlyuses, to avoid churning.

    If either of these parameters are greater than zero, statement pooling will be enabled. If both parameters are greater than zero, both limits will be enforced. If only one is greater than zero, statement pooling will be enabled, but only one limit will be enforced.

    大概意思就是這兩個,有一個值如果大于0,c3p0的statement pool就會發生作用。

    以上所有的配置都是基于c3p0的最新版本。PS一下,還是2015年的JAR。



    通過引入最新的C3P0包,另外增加了兩段配置,線上觀察兩天,問題解決。



    最后打個小廣告,JAVA世界最快的JDBC連接池,非HikariCP莫屬。已經甩c3p0好幾個街角,有圖有真像。





    我的微信公眾號,歡迎溝通學習。
    posted on 2017-11-10 15:25 alexcai 閱讀(1799) 評論(0)  編輯  收藏

    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 亚洲日本VA中文字幕久久道具| 亚洲免费视频网站| 亚洲色偷偷偷综合网| 亚洲w码欧洲s码免费| 91亚洲视频在线观看| 91精品免费在线观看| 亚洲一区电影在线观看| 无码国产精品久久一区免费| 美女视频黄免费亚洲| 成人av免费电影| 狠狠热精品免费观看| 亚洲日本在线观看视频| 羞羞视频免费网站在线看| 亚洲成a人片在线观看日本| 久久久久久AV无码免费网站| 亚洲国产精品免费在线观看| 午夜成人免费视频| 美景之屋4在线未删减免费 | 亚洲阿v天堂在线2017免费| 免费无码一区二区| 亚洲AV日韩AV永久无码绿巨人 | 免费人成在线观看播放a| 色噜噜亚洲精品中文字幕| 99re6热视频精品免费观看| 亚洲免费电影网站| 亚洲国产精品成人一区| 青柠影视在线观看免费高清| 亚洲美女精品视频| 成人免费无码大片A毛片抽搐 | 黄色网址大全免费| 亚洲AV综合色区无码另类小说| 一级女人18毛片免费| 国产精品久久亚洲一区二区| 亚洲高清国产AV拍精品青青草原| 114级毛片免费观看| 麻豆亚洲AV成人无码久久精品 | 国产日产成人免费视频在线观看| 男女一边桶一边摸一边脱视频免费| 亚洲五月六月丁香激情| 国产区卡一卡二卡三乱码免费| 免费国产成人α片|