Object Poolパターン

Object Poolの必要性

　今回はObject Poolパターンについて説明します。Object Poolは、オブジェクトの生成に関するパターンでオブジェクトの数を制限して再利用したい場合に利用するパターンになります。このパターンを利用するケースとして、オブジェクトの生成にコストがかかる場合や、オブジェクトをある数だけ用意して並行処理を行うような場合が考えられます。具体的には、データベースのコネクションやEJBオブジェクトなどにオブジェクトプールが利用されています。

　データベースへのアクセスでは、コネクションの確立にコスト（時間）がかかります。そのため、コネクションプールを使って、データベース接続のコストを下げ、接続を再利用しています。Webシステムでは、図1のようにマルチスレッドで動作しているサーブレットから呼び出される処理（Business Logic）の中で、コネクションを取得してデータベースアクセスを行います。コネクションプールを使っている場合、DataSourceは、起動時にあらかじめコネクションオブジェクトをいくつか用意しておきます（*1）。DataSourceに対して、getConnectionメソッドを呼び出したときには、すでに用意されているプールから、コネクションオブジェクトが返されます。

　Business Logicでは、コネクションを使って処理を実行した後、コネクションをクローズします。コネクションプールを使わない場合は、コネクションをクローズすると実際のデータベースへの接続も終了してコネクションオブジェクトも消滅しますが、コネクションプールの場合は、クローズしてもコネクションオブジェクトがプールに戻されるだけで、実際のデータベースへの接続は終了しません。プールに戻されたコネクションオブジェクトは、利用可能状態（未利用状態）になり、次の処理で再利用されます。


*1：起動時に用意されるコネクションの数は設定によって変わります。設定によっては起動時に用意される数は0にしておいて、必要になってからコネクションを用意する（接続を行う）といったことも可能です。

コネクションプールのメリット

　こうしたコネクションプールの利用の目的はスループットの向上です。データベースへの接続は、一般に数十ミリ秒から数百ミリ秒以上かかる「重たい」処理ですが、コネクションプールを使うことでBusiness Logicがコネクションオブジェクトの取得するににかかる時間が数ミリ秒ですむようになります。結果として、Business Logicの処理時間が短くなり、全体の単位時間あたりの処理量（スループット）も向上します。

　実際に、単純なデータベースアクセスを行う多数のリクエストを処理する場合、コネクションプールの有無によってスループットが10倍～数十倍違うという結果がでます。

　コネクションプール利用のもう1つの利点は、コネクションの上限を制限できることです。コネクションプールに設定された最大値を超えてコネクションを取得しようとすると、コネクションオブジェクトが空くのを待ってからコネクションを返すか、または、取得失敗のエラーを返します（*2）。最大値を設定する理由として、データベースの設定やマシンの能力によって接続数の最大値が決まっているというのがあります。実際に接続する前に、コネクションプール側で接続を制限することで無用なエラーを避けることができます。また、複数のアプリケーション（例えばオンラインとバッチ処理など）で1つのデータベースを利用する場合、それぞれのコネクションプールで接続の上限を設定することで、限られた接続数を最適に割り当てることができます。

　コネクションの最大値は、単に設定可能な上限を守るだけでなく、パフォーマンスチューニングの結果として調整されることがあります。例えば、大量のデータをソートする場合、同時に処理される上限を小さくした方がエラーを起こすことなく、スループットも向上することがあります。ソート処理では、データベース上の一時領域を使いますが、同時に多くの処理を行うと一時領域が足りなくなりデータベース上でエラーになる場合があります。

　また、多数の処理を同時に行うよりも、同時に行う処理数を減らして1つ1つ処理した方がスループットが向上する場合が多いのです。最大値は処理の重さやサーバーの性能によって変わってくるので、負荷テストを行いながら最適値をチューニングする必要があります。

*2：最大値を超えて取得しようとした場合、一定時間コネクションオブジェクトが空くのを待ってコネクションオブジェクトを返すのか、すぐに取得失敗のエラーを返すのかは、コネクションプールの実装や設定によって異なります。