2012-07-31 28 views
5

私たちは、ORMツールとしてhibernateを使用するapiを持っており、c3p0を接続プールハンドラとして使用しています。我々は負荷がかかっているときに問題はありません。しかし、apiが1日ほど休止していない場合、「接続を確立できません」という例外が発生しています。したがって、週末に本体にapiを使用していない場合は、月曜日の朝に接続エラーが発生します。非アクティブ期間後の接続タイムアウト値

Caused by: java.sql.SQLException: An attempt by a client to checkout a Connection has timed out. 

私たちはデータベースとしてmysqlを使用します。私の研究では、mySQLが8時間ほど後に接続が古くなってしまうことを知りました。接続プールがクライアントへの古い接続、したがってクライアントの接続タイムアウト例外を出す可能性があります。

現時点では、C3Poで設定された接続テストはありません。 IdleTestPeriodを使用してプールがクライアントに渡される前に接続をテストするとします。その後、すべての接続がある時点でテストに失敗したらどうなりますか?それらの失敗した接続はプールから削除され、新しいアクティブな接続が再度生成されますか?

現在、これは私たちが使用しているc3p0の設定です。この問題に対して可能な他の理由はありますか?

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close"> 
     <property name="driverClass" value="${----}"/> 
     <property name="jdbcUrl" value="${----}"/> 
     <property name="user" value="${----}"/> 
     <property name="password" value="${------}"/> 
     <property name="minPoolSize" value="5"/> 
     <property name="acquireIncrement" value="5" /> 
     <property name="maxPoolSize" value="125" /> 
     <property name="maxStatements" value="10" /> 
     <property name="maxIdleTime" value="180" /> 
     <property name="maxIdleTimeExcessConnections" value="30" /> 
     <property name="checkoutTimeout" value="3000" /> 
     <property name="preferredTestQuery" value="SELECT 1" /> 
    </bean> 

MySQL Java Connector高可用性およびクラスタリングのセクションで助け

答えて

1

ためのおかげで、プロパティを見てみましょう。具体的にはautoReconnectおよびautoReconnetForPoolsである。 JDBC接続URLのプロパティを使用します。 MySQL、Hibernate、C3P0を使用しているとき、彼らは以前私を助けてくれました。これが役立つことを願っています。

9

チェックアウト時間が3秒(3000ミリ秒)に設定されています。それはあなたの見ている例外です。クライアントはプールからConnectionをチェックアウトするために3秒待つだけで済みます。 3秒で十分でない場合、彼らはあなたの例外を見る。

なぜ、クライアントはConnectionを取得するのに時間がかかるのですか?通常、Connectionをチェックアウトするのは非常に高速です。しかし、すべての接続がチェックアウトされている場合、クライアントはデータベースからConnection取得を待つ必要があります(遅い)。

あなたはかなり積極的に接続を切断するようにプールを設定しました。 minPoolSize = 5より上の任意の数の接続は、maxIdleTimeExcessConnections = 30秒を超えてアイドル状態であれば破棄されます。それでも、あなたのプールは大規模バースト用に設定されています:maxPoolSize = 125。あなたのアプリケーションがしばらく静かで、その後クライアントからの接続要求のバーストを取得するとします。プールはすぐにConnectionsから使い果たし、acquireIncrement = 5のバーストで取得を開始します。しかし、突然25のクライアントがあり、そのプールに5つの接続しかない場合、25番目のクライアントがConnectionを取得する前にタイムアウトになることはあまりありません。

できることはたくさんあります。これらの微調整は分離可能で、あなたが合っているかのように混在または一致させることができます。

1)アイドル "過剰"接続をあまり積極的に切断しないでください。一般的に、プールには要求のバーストを処理する能力があります。 maxIdleTimeExcessConnectionsを完全に削除し、maxIdleTime = 180秒後にゆっくりとConnectionsを使用しないようにすることができます。 (不十分な時間の間、より長い資源のフットプリント)

2)プールが接続が少なすぎるという活動のバーストを見ることはないように、minPoolSizeをより高い値に設定しますより大きな永続的なリソースフットプリント。)

3)設定からcheckoutTimeoutを削除します。 c3p0のデフォルトは、クライアントがConnectionを無限に待機できるようにすることです。 (おそらく、可能性のある成功を待つのではなく、すぐに失敗を報告することをクライアントに薦めているかもしれません。)

あなたが観察している問題は、接続テストやMySQLのタイムアウト自体とはあまり関係ありません。それはそれらの問題に対処すべきではありません。私は、MySQL再接続の問題に関するノーベルのアドバイスをお伝えします。 (私は大規模なMySQLユーザではありません)。接続テストの実装を検討する必要があります。 preferredTestQueryがあるので、テストは合理的に速くなければなりません。私の通常の選択は、testConnectionOnCheckinとidleConnectionTestPeriodを使用することです。 http://www.mchange.com/projects/c3p0/#configuring_connection_testing

幸運を祈ってください!

関連する問題