Seam grew out of the frustration of the Hibernate team with the statelessness typical of the previous generation of Java application architectures. The state management architecture of Seam was originally designed to solve problems relating to persistence — in particular problems associated with optimistic transaction processing. Scalable online applications always use optimistic transactions. An atomic (database/JTA) level transaction should not span a user interaction unless the application is designed to support only a very small number of concurrent clients. But almost all interesting work involves first displaying data to a user, and then, slightly later, updating the same data. So Hibernate was designed to support the idea of a persistence context which spanned an optimistic transaction.

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

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

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

EJB セッション Bean は宣言型トランザクション管理を特長としています。 EJB コンテナは Bean が呼び出されると透過的にトランザクションを起動し、 呼出しが終了するとトランザクションも終了させることが可能です。 JSF アクションリスナーとして動作するセッション Bean メソッドを記述する場合、 そのアクションに関連するすべての作業を 1 つのトランザクションで行うことができ、 アクションの処理が完了したら必ずコミットまたはロールバックされるようにすることができます。 これは素晴らしい機能であり、 いくつかの Seam アプリケーションに必要とされるものはこれだけです。

ただし、 この方法には問題が 1 つあります。 Seam アプリケーションは一つの要求において、一つのセッション Bean への単一のメソッド呼び出しですべてのデータアクセスを終えるわけではない可能性があります。

1 要求ごとのトランザクション数が多くなると、 使用しているアプリケーションが多くの並列要求を処理している際にそれだけ多くのアトミック性と独立性の問題に遭遇する可能性が高くなります。 書き込み動作はすべて、 必ず、 同じトランザクション内で起こらなければならないからです。

Hibernate ユーザーはこの問題を回避するため 「open session in view」 パターンを開発しました。 Spring のようなフレームワークはトランザクションスコープの永続コンテキストを使用しており、 ビューのレンダリングはフェッチされない関連がアクセスされると LazyInitializationException を引き起こすため、 Hibernate コミュニティでは「open session in view」は歴史的により重要でした。

This pattern is usually implemented as a single transaction which spans the entire request. There are several problems with this implementation, the most serious being that we can never be sure that a transaction is successful until we commit it — but by the time the "open session in view" transaction is committed, the view is fully rendered, and the rendered response may already have been flushed to the client. How can we notify the user that their transaction was unsuccessful?

Seam はトランザクション独立性の問題と関連フェッチの問題の両方を解決しながら、 「open session in view」に関する問題を回避します。 解決法は二つに分けられます。

次のセクションでは、 対話スコープの永続コンテキストの設定方法について説明していきますが、 まず最初に Seam トランザクション管理を有効にする方法を説明しておく必要があります。 Seam トランザクション管理なしで対話スコープの永続コンテキストを使用することができ、 また Seam 管理永続コンテキストを使用していない場合でも Seam トランザクション管理を利用すると便利なことがあるので留意しておいてください。 ただし、 この二つの機能は連携して動作するよう設計されているため、 併用する方が最適です。

Seam トランザクション管理は EJB 3.0 コンテナ管理の永続コンテキストを使用している場合でも役に立ちますが、 Java EE 5 環境の外側で Seam を使用する場合、 あるいはこれ以外の Seam 管理の永続コンテキストを使用するような環境で特に役立ちます。

<core:init transaction-management-enabled="false"/>

        

<transaction:no-transaction />

<transaction:ejb-transaction />

<transaction:entity-transaction entity-manager="#{em}"/>

<transaction:hibernate-transaction session="#{hibernateSession}"/>

<transaction:no-transaction />

Seam を Java EE 5 環境の外で使用している場合、 コンテナによる永続コンテキストのライフサイクルの管理は期待できません。 EE 5 環境であっても、 単一の対話の範囲内で連携する多くの疎結合コンポーネントを持つ複雑なアプリケーションがあるかもしれず、 この場合にはコンポーネント間での永続コンテキストの伝播が簡単ではなくエラーが発生しやすい場合があります。

いずれの場合でも、 コンポーネントで 管理永続コンテキスト (JPA 用) または 管理セッション (Hibernate 用) のいずれかを使用する必要があります。 Seam 管理永続コンテキストは単に組み込みの Seam コンポーネントです。 対話コンテキストで EntityManager または Session のインスタンスを管理します。 @In でインジェクトすることができます。

Seam 管理の永続コンテキストはクラスタ化された環境で非常に効率的です。 EJB 3.0 の仕様ではコンテナがコンテナ管理拡張永続コンテキストに対して行うことが許可されていないような最適化を Seam は実行することができます。 ノード間の永続コンテキストの状態を複製することなく拡張永続コンテキストの透過的なフェールオーバーをサポートします。 (この見過ごされてしまった点については、 次回の EJB 仕様のリビジョンで修正したいと考えています。)

<persistence:managed-persistence-context name="bookingDatabase" 

                                  auto-create="true"

                   persistence-unit-jndi-name="java:/EntityManagerFactories/bookingData"/>

<property name="jboss.entity.manager.factory.jndi.name" 

          value="java:/EntityManagerFactories/bookingData"/>

@In EntityManager bookingDatabase;

<persistence:hibernate-session-factory name="hibernateSessionFactory"/>



<persistence:managed-hibernate-session name="bookingDatabase" 

                                auto-create="true"

                  session-factory-jndi-name="java:/bookingSessionFactory"/>

<session-factory name="java:/bookingSessionFactory">

    <property name="transaction.flush_before_completion"

>true</property>

    <property name="connection.release_mode"

>after_statement</property>

    <property name="transaction.manager_lookup_class"

>org.hibernate.transaction.JBossTransactionManagerLookup</property>

    <property name="transaction.factory_class"

>org.hibernate.transaction.JTATransactionFactory</property>

    <property name="connection.datasource"

>java:/bookingDatasource</property>

    ...

</session-factory

>

@In Session bookingDatabase;

@In EntityManager em; //a Seam-managed persistence context


@Begin(flushMode=MANUAL)

public void beginClaimWizard() {

    claim = em.find(Claim.class, claimId);

}

public void addPartyToClaim() {

    Party party = ....;

    claim.addParty(party);

}

@End

public void commitClaim() {

    em.flush();

}

<begin-conversation flush-mode="MANUAL" />

<components xmlns="http://jboss.com/products/seam/components"
   xmlns:core="http://jboss.com/products/seam/core">
   <core:manager conversation-timeout="120000" default-flush-mode="manual" />
</components
>

EntityManager インタフェースにより getDelegate() メソッドを通じてベンダー固有の API にアクセスすることができます。 必然的に、 Hibernate が最も関心の高いベンダーとなり、 org.hibernate.Session が最も強力となるデリゲートインタフェースになります。 これ以外を使用するのがばかばかしくなるほどです。 これは偏見抜きの意見です。 別の JPA プロバイダを使用しなければならない場合は 代替の JPA プロバイダを使用する をご覧ください。

ただし、 Hibernate またはそれ以外のものいずれを使用するかに限らず、 いずれは Seam コンポーネントでデリゲートを使用したくなる場合がくるでしょう。 以下にその一例を示します。

@In EntityManager entityManager;


@Create

public void init() {

    ( (Session) entityManager.getDelegate() ).enableFilter("currentVersions");

}

型キャストは Java 言語の中でも間違いなく繁雑な構文になるため、 できる限り避けるのが一般的です。 デリゲートで取得する別の方法を次に示します。 まず、 以下の行を components.xml に追加します。

<factory name="session" 

         scope="STATELESS" 

         auto-create="true" 

         value="#{entityManager.delegate}"/>

これでセッションを直接インジェクトできるようになります。

@In Session session;


@Create

public void init() {

    session.enableFilter("currentVersions");

}

Seam 管理の永続コンテキストを使用する場合や @PersistenceContext を使ってコンテナ管理の永続コンテキストをインジェクトする場合、 Seam は EntityManager または Session オブジェクトをプロキシします。 これにより、 EL 式をクエリー文字列内で安全かつ効果的に使用することができるようになります。 たとえば、 次を見てください。

User user = em.createQuery("from User where username=#{user.username}")

         .getSingleResult();

上記の例は、 以下の例と同等になります。

User user = em.createQuery("from User where username=:username")

         .setParameter("username", user.getUsername())

         .getSingleResult();

当然、 次のようには絶対に記述しないでください。

User user = em.createQuery("from User where username=" + user.getUsername()) //BAD!

         .getSingleResult();

(効率が悪く、 SQL インジェクション攻撃に対して脆弱となります。)

Hibernate 固有の斬新な機能が フィルタ になります。 フィルタによりデータベース内のデータ表示に制限を与えることができるようになります。 フィルタについては Hibernate のドキュメントで詳細に説明されています。 ここでは、 フィルタを Seam アプリケーションに統合する簡単な方法を記載しておくのがよいだろうと思います。 特に Seam Application Framework でうまく動作する方法を説明します。

Seam 管理の永続コンテキストはフィルタの一覧を定義することができます。 これらは EntityManager や Hibernate Session がはじめて作成されたときに有効になります。 (当然、 Hibernate が永続を実現する構成要素である場合にのみ使用できます。)

<persistence:filter name="regionFilter">

    <persistence:name

>region</persistence:name>

    <persistence:parameters>

        <key

>regionCode</key>

        <value

>#{region.code}</value>

    </persistence:parameters>

</persistence:filter>



<persistence:filter name="currentFilter">

    <persistence:name

>current</persistence:name>

    <persistence:parameters>

        <key

>date</key>

        <value

>#{currentDate}</value>

    </persistence:parameters>

</persistence:filter>



<persistence:managed-persistence-context name="personDatabase"

    persistence-unit-jndi-name="java:/EntityManagerFactories/personDatabase">

    <persistence:filters>

        <value

>#{regionFilter}</value>

        <value

>#{currentFilter}</value>

    </persistence:filters>

</persistence:managed-persistence-context

>