多くの JDBC ドライバでは、ある時点でたった 1 つのスレッドだけが Connection オブジェクトを使用できるという問題があります。 この問題がなければ、あるスレッドが結果を受け取っている時に別のスレッドが問い合わせを送ることができます。 この問題は深刻なものです。
PostgreSQL JDBC ドライバはスレッドセーフです。 したがって、アプリケーションで複数のスレッドを使用する場合、同時にデータベースを使用するスレッドがないことを確実にするための複雑なアルゴリズムを考える必要がありません。
スレッドが別のスレッドが使用している時に接続を使用しようとすると、他のスレッドが完了するまでその操作は待たされます。 通常のSQL文の場合、操作とは文を送信し、何らかの ResultSet を（完全に）受け取ることです。 近道呼び出し（つまり ラージオブジェクトからブロックを読むこと）の場合、それはブロックを送信する、または、受け取る瞬間です。
これはアプリケーションやアプレットでは優れていますが、サーブレットの場合は性能に関する問題を発生させます。 問い合わせを実行する複数のスレッドがある場合、1つを除く各スレッドは待機してしまいます。 これを解消するために、接続プールを作成することをお勧めします。 スレッドがデータベースを使用する必要が発生した時に、スレッドは Connectionの入手を管理クラスに依頼します。 管理クラスは空いている接続をそのスレッドに渡し、その接続に使用中と印を付けます。 空き接続がなければ、接続を開きます。 スレッドが処理を終えた段階で、管理クラスに返却します。 管理クラスはその接続を閉じることも、また、プールに追加することもできます。 また、管理クラスは接続が現在も有効かどうか点検し、もし無効であればそれをプールから削除します。 接続プールの欠点は、各Connection用に新しくセッションが作成されることに伴い、サーバへの負荷が増加することです。 これはアプリケーションの仕様によります。