前回のDataSource管理編で、Connection(DB接続)を得る方法については確立できました。今回は得られたConnectionを、どのように維持・利用するかについて考えてみます。
DB接続は必要になったときに毎回取得するというのも１つの案です。
しかし、複数の処理をまとめてコミット/ロールバックすることを考えると、必要になるたびにDB接続を取得/返却しないほうがよさそうです。つまり、まとまった処理単位で、DB接続を保持し続けたほうが、コミット/ロールバックする際に都合が良いです。
※J2EEにはJTA(Java Transaction API)という技術があります。これを利用すると、トランザクション管理のために、DB接続を保持する必要はありません。が、ここではJTAを使わない方法を説明しています。
Webアプリケーションの場合は、下図のように処理が流れます。
ブラウザからリクエストされた内容は、Actionが呼び出され、BusinessLogicが呼び出され、表示用データを作成後、JSPに転送されます。
※より階層化された設計の場合は、DAO層を設けその中にデータベースアクセス処理を分割させますが、前回も書いたとおりシンプルでレガシーな構成を想定しています。
Actionチェインしている場合には次のようになります。
Action1とAction2の処理を同一トランザクションで行うという前提で設計します。
例えば、登録Action→再表示Actionのようなケースで、再表示Actionで例外が発生した場合に、登録はロールバックするものとします。
一連の矢印内のどこからで参照できるようにするにはThreadLocalというクラスを使うのが便利です。
ThreadLocalは同一スレッド限定のグローバル変数のようなものです。一連の矢印は同一スレッドで処理されるので、横断的にコネクションを保持することができます。
図の青点線になってからは、最初に取得したDB接続を保持し続けます。最後にCommitかRollbackの判断をします。
- リクエストがサーバーに受け付けられ、スレッドの一連の処理が開始します
- スレッド内で初めてDB接続を使用し始めたときにDB接続を取得します
- ここで取得したDB接続は、Responseを返却する直前まで保持しつづけます
- Responseを返却する直前で、コミット/ロールバックを行い、DB接続を返却します
長くなったので、ThreadLocalを使ったサンプルソースプログラムは、次回紹介します。
