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

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

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

    隨筆-35  評(píng)論-33  文章-0  trackbacks-0
      置頂隨筆

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



    異常截圖

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

    經(jīng)過查看官方文檔:http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads



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

    再貼一個(gè)官方的說明:

    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.

    大概意思就是這兩個(gè),有一個(gè)值如果大于0,c3p0的statement pool就會(huì)發(fā)生作用。

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



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



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



    posted @ 2017-11-10 15:25 alexcai 閱讀(1811) | 評(píng)論 (0)編輯 收藏
         摘要: 在word的處理之中,文字,各種類型的圖片,最復(fù)雜的公式,之前編寫的API基本都覆蓋了。不過,昨天在做一個(gè)文檔測(cè)試時(shí),發(fā)現(xiàn)表格沒有能很好的處理。  閱讀全文
    posted @ 2017-08-25 15:54 alexcai 閱讀(769) | 評(píng)論 (0)編輯 收藏
         摘要: 作為日常支付業(yè)務(wù),微信的接入逐漸進(jìn)入了大家的視野。今天以PC端接入微信支付的基本流程來說明。  閱讀全文
    posted @ 2016-07-26 11:59 alexcai 閱讀(1454) | 評(píng)論 (2)編輯 收藏
         摘要: 在WORD里面編輯公式,目前是有兩種方法。  閱讀全文
    posted @ 2016-07-15 08:30 alexcai 閱讀(2210) | 評(píng)論 (1)編輯 收藏
         摘要: 當(dāng)我們淡到RPC服務(wù)框架,放眼世界范圍,我目前知道的主流有thrift,fingle,grpc等。當(dāng)然大型互聯(lián)網(wǎng)公司都會(huì)有自己的RPC服務(wù)與治理框架。經(jīng)過一段時(shí)間的調(diào)研,本著簡(jiǎn)單,高效的原則,最終選擇thrift.具體原因,等接下來寫到服務(wù)篇的時(shí)候再細(xì)說。  閱讀全文
    posted @ 2016-06-29 18:14 alexcai 閱讀(1537) | 評(píng)論 (2)編輯 收藏
         摘要: 目前公司業(yè)務(wù)上,有課程直播這一塊。為了增加用戶的互動(dòng),需要增加聊天室功能。聊天室,對(duì)實(shí)時(shí)性有較嚴(yán)格的要求,所以考慮使用socketio來做。目前在服務(wù)端,有基于netty實(shí)現(xiàn)的websocketio的框架。https://github.com/mrniko/netty-socketio,這個(gè)作者還是挺厲害的(redisson的作者)。  閱讀全文
    posted @ 2016-06-06 08:37 alexcai 閱讀(3052) | 評(píng)論 (2)編輯 收藏
         摘要: 對(duì)于后端的參數(shù)校驗(yàn),我們一直在強(qiáng)調(diào)的驗(yàn)證規(guī)則,提示信息的重用。這不,springmvc通過集成Valid最大程序減少了我們的工作量。其實(shí)后端的參數(shù)過濾,是分幾種請(qǐng)求來源的。每種的處理都不太一樣,但是我們?nèi)绻苤赜抿?yàn)證規(guī)則,提示信息,那就很強(qiáng)大了。  閱讀全文
    posted @ 2015-11-27 17:12 alexcai 閱讀(5602) | 評(píng)論 (3)編輯 收藏
      2017年11月10日

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



    異常截圖

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

    經(jīng)過查看官方文檔:http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads



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

    再貼一個(gè)官方的說明:

    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.

    大概意思就是這兩個(gè),有一個(gè)值如果大于0,c3p0的statement pool就會(huì)發(fā)生作用。

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



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



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



    posted @ 2017-11-10 15:25 alexcai 閱讀(1811) | 評(píng)論 (0)編輯 收藏
      2017年8月25日
         摘要: 在word的處理之中,文字,各種類型的圖片,最復(fù)雜的公式,之前編寫的API基本都覆蓋了。不過,昨天在做一個(gè)文檔測(cè)試時(shí),發(fā)現(xiàn)表格沒有能很好的處理。  閱讀全文
    posted @ 2017-08-25 15:54 alexcai 閱讀(769) | 評(píng)論 (0)編輯 收藏
      2017年7月24日
         摘要: HDFS和MapReduce是Hadoop的兩大核心,除此之外Hbase、Hive這兩個(gè)核心工具也隨著Hadoop發(fā)展變得越來越重要。今天我們只初步的看看HDFS.  閱讀全文
    posted @ 2017-07-24 10:35 alexcai 閱讀(671) | 評(píng)論 (0)編輯 收藏
      2017年6月29日
         摘要: 使用thrift已經(jīng)有段時(shí)間了,目前基本是clien+server的方式,負(fù)載是通過nginx來處理。這種處理方式有兩個(gè)比較大的弊端:  閱讀全文
    posted @ 2017-06-29 16:39 alexcai 閱讀(895) | 評(píng)論 (0)編輯 收藏
      2017年6月2日
        www.taggerin.com,主要處理日常文檔的在線編輯,以及與Markdown,PDF,html等格式的雙向轉(zhuǎn)換.聽說內(nèi)測(cè)版本已經(jīng)發(fā)布。真正的文檔在線編輯與預(yù)覽。?
    posted @ 2017-06-02 09:45 alexcai 閱讀(721) | 評(píng)論 (0)編輯 收藏
      2016年12月15日
         摘要: 一般的業(yè)務(wù)開發(fā),不會(huì)涉及到多種數(shù)據(jù)庫(kù)類型的操作。因?yàn)椋瑹o論是對(duì)于開發(fā),還是運(yùn)維,成本都是非常高的。如果是ORACLE數(shù)據(jù)庫(kù)到MYSQL的數(shù)據(jù)備份,目前我所了解的開源解決方案有2種:  閱讀全文
    posted @ 2016-12-15 13:33 alexcai 閱讀(1247) | 評(píng)論 (0)編輯 收藏
      2016年7月26日
         摘要: 作為日常支付業(yè)務(wù),微信的接入逐漸進(jìn)入了大家的視野。今天以PC端接入微信支付的基本流程來說明。  閱讀全文
    posted @ 2016-07-26 11:59 alexcai 閱讀(1454) | 評(píng)論 (2)編輯 收藏
      2016年7月15日
         摘要: 在WORD里面編輯公式,目前是有兩種方法。  閱讀全文
    posted @ 2016-07-15 08:30 alexcai 閱讀(2210) | 評(píng)論 (1)編輯 收藏
      2016年7月8日
         摘要: 最近在弄項(xiàng)目的壓測(cè),首先想到把應(yīng)用服務(wù)器TOMCAT的相關(guān)配置升級(jí),網(wǎng)上看了很多關(guān)于TOMCAT升級(jí)的案例,于是結(jié)合自己的實(shí)際情況,做了筆記。  閱讀全文
    posted @ 2016-07-08 09:50 alexcai 閱讀(1575) | 評(píng)論 (2)編輯 收藏
      2016年6月29日
         摘要: 當(dāng)我們淡到RPC服務(wù)框架,放眼世界范圍,我目前知道的主流有thrift,fingle,grpc等。當(dāng)然大型互聯(lián)網(wǎng)公司都會(huì)有自己的RPC服務(wù)與治理框架。經(jīng)過一段時(shí)間的調(diào)研,本著簡(jiǎn)單,高效的原則,最終選擇thrift.具體原因,等接下來寫到服務(wù)篇的時(shí)候再細(xì)說。  閱讀全文
    posted @ 2016-06-29 18:14 alexcai 閱讀(1537) | 評(píng)論 (2)編輯 收藏
    僅列出標(biāo)題  下一頁(yè)
    主站蜘蛛池模板: 亚洲一级片免费看| 女人18毛片水最多免费观看| 免费在线观看a级毛片| 亚洲jjzzjjzz在线观看| 在线观看免费av网站| 亚洲黄色在线播放| 精品福利一区二区三区免费视频| 亚洲天堂电影在线观看| 91在线手机精品免费观看| 亚洲精品日韩中文字幕久久久| 最近免费中文字幕高清大全| 亚洲欧洲尹人香蕉综合| 99精品国产免费久久久久久下载 | 亚洲中文久久精品无码1| 最近中文字幕完整版免费高清| 亚洲日本视频在线观看| 成全视频免费高清| 免费播放美女一级毛片| 亚洲精品无码永久在线观看| 羞羞视频免费网站在线看| 亚洲一区二区三区首页| 日本免费网址大全在线观看 | 亚洲影院在线观看| 成人免费视频77777| 疯狂做受xxxx高潮视频免费| 亚洲中文字幕伊人久久无码| 久久精品免费观看| 色在线亚洲视频www| 免费在线观看污网站| 嫩草成人永久免费观看| 亚洲av永久综合在线观看尤物 | 亚洲综合网站色欲色欲| 日韩免费高清大片在线| 亚洲欧美日韩中文二区| 久久久久亚洲AV无码专区桃色| 久久A级毛片免费观看| 精品久久久久久亚洲中文字幕| 亚洲综合另类小说色区| 日韩精品无码区免费专区 | 在线观看午夜亚洲一区| 黄色网址免费大全|