HibernateがPreparedStatementインスタンス自体を実際に保存するのか、それとも接続プロバイダーに依存してそれらを再利用するのか、私は覚えていません。 （BatcherImplのクイックスキャンは、同じSQLを連続して複数回実行する場合、最後のPreparedStatementを再利用することを示唆しています）
c3p0ドキュメントが作成しようとしているポイントは、多くのJDBCドライバーでは、PreparedStatementが役に立たないことだと思います。一部のドライバーは、クライアント側でパラメーターをスプライシングし、ビルドされたSQLステートメントをデータベースに渡すだけです。 。これらのドライバーにとって、PreparedStatementsはまったく利点がなく、それらを再利用するためのあらゆる努力が無駄になります。 （Postgresql JDBC FAQによると、これはサーバープロトコルバージョン3より前のPostgresqlの場合であり、ドキュメントに詳細情報があります）。
PreparedStatementsを有効に処理するドライバーの場合でも、メリットを得るには、PreparedStatementインスタンスを実際に再利用する必要があります。たとえば、ドライバーが実装する場合：
- Connection.prepareStatement（sql）-サーバー側のステートメントを作成します
- PreparedStatement.execute（..）など-そのサーバー側のステートメントを実行します
- PreparedStatement.close（）-サーバー側のステートメントの割り当てを解除します
この場合、アプリケーションが常にプリペアドステートメントを開き、一度実行してから再度閉じると、まだあります。 メリットはありません。実際、往復が増える可能性があるため、状況はさらに悪化する可能性があります。したがって、アプリケーションはPreparedStatementインスタンスに固執する必要があります。もちろん、これは別の問題につながります。アプリケーションがあまりにも多くにハングアップし、各サーバー側ステートメントがいくつかのリソースを消費する場合、これはサーバー側の問題につながる可能性があります。誰かがJDBCを直接使用している場合、これは手動で管理される可能性があります。一部のステートメントは再利用可能であることがわかっているため、準備されています。一部はそうではなく、代わりに一時的なステートメントインスタンスを使用します。 （これは、プリペアドステートメントの他の利点である引数のエスケープの処理をスキップしています）
したがって、c3p0およびその他の接続プールにもステートメントキャッシュが用意されているのはこのためです。これにより、アプリケーションコードはこれらすべての処理を回避できます。ステートメントは通常、限られたLRUプールに保持されるため、一般的なステートメントはPreparedStatementインスタンスを再利用します。
パズルの最後のピースは、JDBCドライバー自体が賢くてこれを行うことを決定するかもしれないということです。また、サーバー自体も賢く、前のステートメントと構造的に類似したステートメントを送信しているクライアントを検出することを決定する場合があります。
Hibernate自体がPreparedStatementインスタンスのキャッシュを保持しないことを考えると、それらの利点を得るには、c3p0にそれを実行させる必要があります。 （キャッシュされたプランを再利用するため、一般的なステートメントのオーバーヘッドを削減する必要があります）。 c3p0がプリペアドステートメントをキャッシュしない場合、ドライバーは、アプリケーションがステートメントを準備し、実行してから、再度閉じることを確認します。 JDBCドライバーには、アプリケーションが常にこれを行う場合にサーバーの準備/実行のオーバーヘッドを回避するための「しきい値」設定があるように見えます。したがって、はい、c3p0にステートメントキャッシングを実行させる必要があります。
お役に立てば幸いです。申し訳ありませんが、少し時間がかかります。答えははいです 。