問題タブ [c3p0]

誰かが接続とステートメントのプーリングとは何か、またプールされていないデータソースよりも優れている点を説明できますか? プロジェクトで c3p0 や proxool などのテクノロジーを使用するのが良いアイデアである場合を理解しようとしています。まず、それらが何をするのか、いつそれらを使用するのが興味深いのかを理解する必要があります。どうもありがとうございました。

MySQL 5.1.30 と一緒に Hibernate を使用しています。

次のライブラリがあります。

• c3p0-0.0.1.2.jar
• mysql-connector-java-5.0.3-bin.jar
• hibernate3.jar

構成に hibernate.cfg.xml を使用します。

JAVA persistance with hibernate bookでは、c3p0 構成オプションが説明されています。

• hibernate.c3p0.min_sizeこれは、C3P0 が常に準備しておく JDBC 接続の最小数です。
• hibernate.c3p0.max_sizeこれは、プール内の接続の最大数です。この数が使い果たされると、実行時に例外がスローされます。
• hibernate.c3p0.timeoutアイドル接続がプールから削除されるまでのタイムアウト期間 (この場合は 300 秒) を指定します。
• hibernate.c3p0.max_statementsキャッシュされるステートメントの最大数。Hibernate で最高のパフォーマンスを得るには、準備済みステートメントのキャッシュが不可欠です。
• hibernate.c3p0.idle_test_periodsこれは、接続が自動的に検証されるまでの秒単位のアイドル時間です。

Java 1.5.0_09 とtomcat 6.0を使用しています。Tomcat に 3 つのアプリケーションをデプロイしています。それらはそれぞれ、上記とほぼ同等の構成ファイルで hibernate を使用します (ユーザー名、データベース名、パスワード、およびマッピングリソースのみが変更されます)。

残念ながら、上記の設定では、数時間実行した後、 Tomcat を強制終了するいくつかの厄介なデッドロック エラーが発生します。

これは、何人かの人々がすでに得たエラーのようです。http://forum.hibernate.org/viewtopic.php?p=2386237で説明されている回避策に従って、設定を次のように変更しました。

新しい設定では、デッドロックは発生しませんが、次のようになります。

私が間違っていることと、c3p0を正しくセットアップする方法を知っている人はいますか?

私が使う

• トムキャット
• C3p0 (Tomcat 内で構成された JNDI)
• データベースとしての MySQL (InnoDB) / Derby (組み込みではない)
• EHCache (メモリー内)
• 休止状態
• Testmachine は WinXP を実行します

開発には Derby を使用していましたが、MySQL に切り替えたいと考えていました。MySQL を使用すると、私のテストが Derby よりも約 50% 遅くなったことに驚きました。

私のテストシナリオ:

• 複雑さの異なる約 2000 の Select がありましたが、複数の結合を使用したものはありませんでした。すべての SQL はインデックスを使用します
• Ehcache はセットアップ実行でいっぱいになります。その後、テストシナリオを少なくとも 50 回実行して、オプティマイザー/GC 効果を克服します

キャッシュが使用されていることを確認しました。データベースに来る実際の SQL はありません。したがって、MySQL テストの速度が低下するのは、接続の作成時間だと思います。

c3p0 を使用して、アプリケーションでのデータベース接続の作成と破棄をログに記録しようとしていますConnectionCustomizer。その中に、次のようなコードがあります。

私はデッドロックに陥っています。c3p0 のライブラリには、同期メソッドを使用する少なくとも 2 つのオブジェクトがあり、意図したロック順序を指定していないようです。接続をログに記録すると、ロックがかかっていてC3P0Registry、最終的にはPoolBackedDataSource(単純にデータソースのリストを作成すると、ハッシュコードにアクセスしてロックが発生します)。

接続プロバイダーをシャットダウンする ( を呼び出すC3P0ConnectionProvider.close()) と、ロックが逆の順序で呼び出されます。しかし、子データソースがシャットダウンされている間、ログがトリガーされています。その結果、デッドロックが発生します。

私がc3p0ライブラリに行っている呼び出しは両方とも有効で、予想される呼び出しのようです:

• C3P0ConnectionProvider.close()
• C3P0Registry.getPooledDataSources()

また、（ドキュメントに明示的に記載されていない限り）独自のロック戦略を管理するのはライブラリの責任であるように思われます。（これは誰かを責めるために言っているのではありません..ベストプラクティスについての私の理解を確認するためだけです）

この問題にどのように対処すればよいですか? c3p0 は最新のメカニズムではなく同期メソッドを使用しているため、実際にロックをテストすることはできません。

DataSourceクロージング コードから、最初にC3P0Registryロックを取得してからDataSource. 私は正しいロック順序を推測していますが、それが快適かどうかはわかりません。

ロギング呼び出しのロック順序を逆にすることはできないと思います。C3P0Registryのリストを取得するにはが必要なので、それらへの参照を取得するために最初にロックしDataSourcesないと をロックできませんでした。DataSourcesC3P0Registry

もちろん、別の解決策は、すべての c3p0 の上に別のより高いレベルのロックを提供することです。接続プールの場合、それはポイントを無効にしているようです。

今のところ、ログをロールバックしています。助けてくれてありがとう。

MySQLの接続は8時間タイムアウトしているようです。HibernateforORMを利用してTomcatで複数のWARを実行しています。8時間後（つまり一晩）、アイドル状態の接続を取得するとパイプが壊れます。

私はすでにコードをトレースし、すべてのトランザクションをコミットまたはロールバックすることを二重に確認しました。

これが私のhibernate.cfg.xmlです

私が修正したと思ったパラメータはc3p0.idle_test_period--です。デフォルトは0です。ただし、8時間実行した後も、パイプの破損の問題が発生します。Google経由で複数の投稿インデックスがありますが、満足のいく答えに到達するものはありません。

MySQLに接続しているJava（JPA + Hibernate + CommonsDBCP）アプリ間で多くの接続の問題が発生しています。私は調査を行い、検証クエリ、タイムアウト、Xの前のテストなどですべての設定を微調整しました。

このパスは、DBCPとC3POを比較する別のStackOverflowの質問につながりました。回答から、代わりにC3POを試してみることにしました。

ただし、途中で別のオプションを見つけました。アプリサーバーとMySQLの両方が同じマシンで実行されているため、名前付きパイプです。問題は、この方法について多くの詳細を見つけることができないということです。

だからここに私の質問があります：最も安定したオプションは何になるでしょう：名前付きパイプ、またはTCP w / C3PO ？どんな話や知識でも、答えだけでなく大歓迎です。

Hibernate を使用して Java SE (注: Java EE ではない) アプリケーションを作成していますが、実行スレッドごとに Hibernate への異なる接続を提供する必要があります。これらの接続はプールする必要があり、それぞれに少なくとも異なる認証があり、場合によっては異なる JDBC URL があります。接続は再利用されます (プーリング要件から推測できます)。

Hibernate/C3P0/et al のどの部分をオーバーライドする必要がありますか? これはこれらのツールで実現できますか? それとも、独自のプーリング データ ソースを作成する必要がありますか?

hibernate-c3p0Mavenのpom.xmlファイルに含めると、ランタイムNoClassDefFoundErrorが見つからないため、ランタイムが取得されますorg.slf4j.impl.StaticLoggerBinder。Maven がこの依存関係を解決するというのが私の印象でした。c3p0 が slf4j を必要とする場合、slf4j がダウンロードされて含まれます。

私のpom.xmlファイルには次のものがあります：

最近、JDBCを手動で処理する代わりにSpring Frameworkに切り替えましたが、これはほとんどの場合、適切な移行です。ただし、あるプログラムで奇妙な問題が発生し始めました。データベースが遅い場合、呼び出すときにデータベースがgetJdbcTemplate().update( ... )戻らないことがあります。

少し調べた後、Apache DBCPからC3POに切り替えましたが、それでも問題は再発しました。

これが私が使用しているコードです：

ログファイルでは次のようになります。

ここにコードがぶら下がっています。通常、次のようになります。

SpringFramework自体からログメッセージが表示されない理由がわかりません。メインコードに次の行を追加しました。

テストメッセージが表示されますが、他には何も表示されません。発散してすみません。

ハングする前に速度が低下していることに気づきました。クエリが最後に正常に実行されたとき、通常の200ミリ秒ではなく、完了するのに1分半かかりました。次回は、プロセスを強制終了する前に25分間実行しました。

作業中のデータベース（InnoDB）に問題があることはわかっていますが、これはタイムアウト後、SpringFrameworkが「あきらめて」ハングするようです。

何かアドバイスをいただければ幸いです。