第10章 Seam とオブジェクト / リレーショナルマッピング

Seam は Java アプリケーションアーキテクチャの旧世代の典型的なステートレス性による煩わしさから生まれました。当初 Seam の状態管理のアーキテクチャは永続性、 特に 楽観的トランザクションの処理 に関する問題を解決する目的で設計されていました。 スケーラブルなオンラインアプリケーションは常に楽観的トランザクションを使用します。 アプリケーションがごく少数の同時クライアントに対応するよう設計されていない限り、 アトミック (データベース／JTA) レベルのトランザクションはユーザー操作にはスパンしないはずです。 しかし、ほとんどすべての作業は最初にユーザーにデータを表示してからそのデータを更新することです。このため、 Hibernate は楽観的トランザクションをスパンした永続コンテキストの概念に対応するよう設計されました。

残念ながら、 Seam や EJB 3.0 より以前の「ステートレス」と呼ばれるアーキテクチャには楽観的なトランザクションを表現するための構成概念がありませんでした。 このため、 代わりにアトミックなトランザクションに対してスコープされる永続コンテキストを提供していました。当然これはユーザーにとって多くの問題を引き起こし、 また Hibernate に関するユーザーからの最大の苦情、 LazyInitializationException の原因となっています。 ここで必要なのはアプリケーション層で楽観的トランザクションを表現する構成概念です。

EJB 3 はこの問題を認識し、 コンポーネントの寿命に対してスコープされる 拡張永続コンテキスト を持ったステートフルなコンポーネント (ステートフルセッション Bean) というアイデアを導入します。 これは問題を解決する完全なソリューションではなく (それ自体は便利な構成です)、 まだこの方法には 2 つの問題が残っています。

Seam は対話を提供することにより 1 番目の問題を解決し、 対話に対してステートフルセッションの Bean コンポーネントをスコープします (ほとんどの対話は実際にはデータ層で楽観的トランザクションを表示します)。Seam 予約サンプルなどの永続コンテキストの伝播を必要としない多くのシンプルなアプリケーションにはこれで十分です。 各対話内で疎に作用しあっているコンポーネントを多く持つもう少し複雑なアプリケーションの場合、 コンポーネント群全体への永続コンテキストの伝播は重要な問題となります。 このため Seam は EJB3 の永続コンテキスト管理モデルを拡張して、対話スコープの拡張永続コンテキストを提供します。