データベース接続によるバックグラウンドカードの死の問題を解決

詳細
 
この間、Demoプロジェクトを書きました.クライアントはネットワーク接続を通じて、nettyが実現したバックグラウンドにアクセスしてデータを取得します.
 
バックグラウンドのnettyの作業タスクもスレッドプールを通じて対応するタスク処理を完了しているが、偶現クライアントはデータを読み取る際に、読み取ったスレッドが引っかかり、データが読めず、たまに現れるだけで、何度も試したが、観察するたびに再現されず、圧力テストさえ現れず、ローカルDebugにもタスクの問題はなかった.各ステップにログを付けることで、タスクがスレッドプールに追加された後、最終的に実行されていないことがわかりました.スレッドプールがいっぱいになって、あるステップにデッドロックが発生したかどうかを妊娠し始めました.コードをよくチェックしても、デッドロックが発生する可能性はありません.
 
何度も問題が発生した後、「よく問題が発生するときは、長い間バックグラウンドを訪問していないので、それから訪問するときは通常の訪問よりも現れやすい」という法則があることに気づいた.
 
以上の法則から推測すると,バックグラウンドのあるリソースが解放されたか,あるいは期限切れで失効したために使用されたリソースはデータベース,springに割り当てられたC 3 P 0のデータベース接続プールのみである可能性がある.プロファイルの表示:
 
 
 

 
 
コンフィギュレーションでcheckoutに接続するのはチェックが入っていて、タイムアウトも長くないので、当然問題ないでしょう.
このパラメータの解釈をよく見ると、testConnectionOnCheckoutは、checkoutのときに、データに対して1回のクエリまたはJDBC 4以上とC 3 P 00である.9.5以降はisValid()を呼び出してチェックします.原理はデータベースに対して最も簡単なクエリーを行うことと理解できます.
それからmysqlが长い间使っていない接続であることを调べて、カードが死ぬ现象が现れて、つまりidle状态で、前にC++アクセスMysqlが现れたことを连想して、最后に自分でスレッドを书いて、时间を隔てて简単な検索をして解决して、実は私のこのような情况はcheckoutの时すでにカードが死んで、接続がタイムアウトするのではありませんて、checkoutスーパーでもないので、C 3 P 0のパラメータ配置を見て、もう一つのidleConnectionTestPeriodがあります.これは定時的にアイドルの接続を「アクティブ化」し、その後、万事順調で、問題は二度と現れませんでした.もう一つのパラメータは公式にも提案されており、組み合わせて使用し、最終的には以下のように構成されています.
 
 

 
 
AutomaticTestTable、これはオプションで、接続プールがテストを行うときにアクセスしたテーブル名が自動的に作成され、select 1などの文が実行され、テーブルが作成された後、手動で変更する必要はありません.
 
 
メモして忘れる.