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