一部でセッションの話が盛り上がっていますが、JavaではFilterあたりでセッションオブジェクトをカスタムのセッションオブジェクトに差し替えます。HttpSessionという型はインターフェイスなので、実際はどんな実装になっていても、機能だけ満たせば問題ありません。
よくセッションで問題となるのが、
- 同一コンテキスト上の他のアプリのセッションの破壊
- スケーラビリティ
- サーブレットAPI依存
あたりです。
セッションの破壊は暗黙の名前空間を取り入れるのがベストでしょう。凪瀬さんのエントリの中にもコメントしましたが、同一アプリ上の同一業務をサブコンテキストとみなし、サブコンテキスト単位で名前空間を暗黙的に持つ方法です。
実セッションにはサブコンテキストを示す名前空間をキーにマップオブジェクトをバインドします。セッションが要求された場合はマップをセッションのインターフェイスでラップして操作させます。アプリ側ではサブコンテキストなんて概念は考える必要はありません。
次にスケーラビリティですが、サーバを複数台にしたい場合や、純粋にセッション数が多くても対処できるようにしたいという場合があります。
サーバを複数台にするためには、AサーバとBサーバがあったとして、Aサーバに格納されたセッションの情報をBサーバで取得できなければなりません。そのためにTomcatあたりではTCPで常にグループ間で同期を取るようになっています。この辺も同期が取られているかをアプリが意識する事はありません。
セッション数に対応するにはDBやファイルシステムに書き込むのがベストでしょう。DBであれば、複数台から同一の情報が取得できる為、分散化にも繋がります。
最後に、サーブレットAPI依存を防いで極力POJOにしたいケースです。この場合はDIコンテナを組み合わせるのがベストでしょう。SpringやSeasar2を使って、セッションをインジェクションし、利用するクラスは単なるドメインモデルとして扱うのがシンプルです。