http://martinfowler.com/bliki/ResourcePool.html

多くのプログラマは生成や維持にコストがかかるリソースを利用する必要がある。そのようなものの例としては、データベースコネクションやスレッドが挙げられる。リソースプールはそれらのリソースを管理するためのよい方法だ。

クライアントがデータベースコネクションを必要とする際は、自身でコネクションを生成するのではなく、プールに対してそれを要求する。クライアントがそのコネクションを使った処理を終えた後は、それをプールに返す。プールは立ち上げ時にたくさんのコネクションを生成しておくケースが多いだろう。プールのサイズは通常構成管理により設定することが可能で、クライアントからの需要の量と、リソースの維持に要するコストに従い調整される。

クライアントが新しく要求を出した際に全てのリソースが使用中だった場合、2つの異なる対応方法がある。ひとつは例外を投げること、もうひとつはリソースが使用可能になるまでクライアントを待たせることだ。もし可能であれば、多くの場合ベストな対応は、プールを拡張し追加のコネクションを生成することだ。そのようにすれば、プールの初期サイズを小さく設定し、必要に応じて拡張させることが出来る。こうすると次は、リソースが残り続けるのが問題である場合に、多くのリソースがアイドル状態である時にプールを縮小するメカニズムが必要になってくるだろう。動的拡張を行う場合であっても、もうこれ以上大きくなってほしくないと考える、プールサイズの上限はやはり必要だろう。

リソースプールを使う場合によくある問題は、クライアントがリソースを返してくれないこと—つまりはリソースリークだ。この問題に対処するよい方法は、テスト中はプールの上限を1に設定しておき、上限に達した状態での要求に対してはプールが例外を投げるようにしておくことだ。これはリークを起こすクライアントの特定を容易にしてくれる。

リソースプールに関するさらに詳しい情報については、POSA 3を参照のこと。