MySQLサーバを頻繁に切断/再接続する必要がありますか？

Question

私のケースでは、javaで作られたアプリケーションがあり、MySQLサーバに一度だけ接続して接続しているということです。それが再びそれを送信しようとしたとき、それはランダムにMySQLへのクエリを送信し、それに単一のクエリを送信せずに多くの時間を滞在することができ、その後、JDBCは言う：

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException：サーバーから正常に受信された最後のパケットは60314秒前です。サーバーに最後に送信されたパケットは60314秒前に送信されました。これはサーバーの設定値 'wait_timeout'よりも長くなります。この問題を回避するには、アプリケーションで使用する前に接続の有効期限を期限切れにしたり、テストしたり、クライアントタイムアウトのサーバー構成値を増やしたり、Connector/J接続プロパティ 'autoReconnect = true'を使用することを検討する必要があります。

、私は心の中で多くのソリューションを持っている： - 設定されていることを「真」に自動再プロパティおよび再接続 - /アプリがクエリを実行し、[それはまた、第二に、多くの問い合わせを行うことができます] 毎回外して接続それがタイムアウトになったとき。 私は第二が好きです。しかし、ここで私の質問が飛び出す：それは短い接続を行うことをお勧めですか？それとも本当に問題ではない？なぜMySQLサーバはwait_timeoutプロパティを保持していますか？

Answer 1

接続処理を接続プールに委ねるのが最善です。ご覧くださいhttp://sourceforge.net/projects/c3p0/

Answer 2

接続プールは1つの回答かもしれませんが、アプリケーションによって異なります。

私は、その論理セッションの長さに妥当な制限がある場合、論理セッションへの接続をスコープすることを望んでいます（例えば、Web要求や電子メールメッセージ）。

新しい「論理セッション」の開始時に新しい接続を開き、それを使用して破棄することは、「不良」または「壊れた」接続が他のセッションに及ぼす影響を最小限に抑えるので有効です。

ただし、ほとんどの場合、個々の操作ごとに接続を更新する必要はありません。これは、シナリオによっては有効な戦略かもしれません。

通常、接続プールは使用間の接続を正しくリセットしません（mysqlでこれを行う唯一の正しい方法は、com_change_userパケットを送信することで、これをサポートするAPIはほとんどなく、アプリケーションの数が少ないことが分かります）おそらく再現不可能なバグを引き起こす可能性があります。