ヘッダーをスキップ

Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド
10g（10.1.3.1.0）
B31852-03
目次
目次		 索引
索引

戻る 次へ

1 Enterprise JavaBeansについて

Java Enterprise Edition（Java EE）Enterprise JavaBeans（EJB）は、エンタープライズ規模のオブジェクト指向分散アプリケーションの開発およびデプロイに使用するコンポーネント・アーキテクチャです。EJBアーキテクチャに従って作成されたアプリケーションは、拡張性が高くトランザクション対応で安全です。作成されるコンポーネント・タイプは、一般にEnterprise JavaBeansと呼ばれます。

この章の内容は次のとおりです。

Enterprise JavaBeansとは

EJBアーキテクチャには、表1-1にリストするオブジェクトを実装するための十分な柔軟性があります。

表1-1    EJBのタイプ 
タイプ  説明  参照先 

セッション 

クライアントの操作を実行するために使用される単一のクライアント/サーバー・セッションの継続時間中、クライアントによって作成されるEJB 3.0またはEJB 2.1コンポーネント。 

「セッションBeanとは」 

    ステートレス 

対話状態を維持しないセッションBean。特定のクライアントに接続していない再利用可能なビジネス・サービスに使用されます。 

「ステートレス・セッションBeanとは」 

    ステートフル 

対話状態を維持するセッションBean。インスタンス変数の値やトランザクション状態などの状態を（存続期間中）維持する単一クライアントとの対話型セッションに使用されます。 

「ステートフル・セッションBeanとは」 

エンティティ 

永続性ユニットで指定されたJava永続性API（JPA）永続性プロバイダを使用してリレーショナル・データベースに格納されている永続データを表すEJB 3.0準拠の軽量エンティティ・オブジェクト（「persistence.xmlファイルとは」を参照）。 

「JPAエンティティとは」 

エンティティBean 

リレーショナル・データベースに格納されている永続データを表すEJB 2.1 Enterprise Beanコンポーネント。 

「EJB 2.1エンティティBeanとは」 

    CMP 

コンテナ管理の永続性（CMP）を備えたエンティティBeanは、そのBeanをホスティングしているコンテナで使用される永続性マネージャに永続性管理を委任するエンティティBeanです。 

「コンテナ管理の永続性を備えたEJB 2.1エンティティBeanとは」 

    BMP 

Bean管理の永続性（BMP）を備えたエンティティBeanは、自身の永続性を管理するエンティティBeanです。 

「Bean管理の永続性を備えたEJB 2.1エンティティBeanとは」 

MDB 

メッセージドリブンBean（MDB）は、Java Message Service（JMS）メッセージの非同期コンシューマとして機能するEJB 3.0またはEJB 2.1コンポーネントです。 

「メッセージドリブンBeanとは」 

詳細は、次を参照してください。

EJB 3.0 Enterprise Beanの構造

EJB 3.0を使用している場合、EJB実装のインタフェースはEJBのタイプによって制限されません。たとえば、JPAエンティティの実装では、Plain Old Java Object（POJO）および任意のPlain Old Java Interface（POJI）を使用してEJBを実装できます。javax.ejb.EntityBeanのようなインタフェースを実装する必要はなく、EJBHome、EJBLocalHome、EJBObjectまたはEJBLocalObjectを拡張する別のインタフェースも不要です。クライアントは、EJB 3.0 POJOエンティティ・インスタンスをnewで（または「JPAエンティティの問合せ方法」に説明されているEntityManagerで）インスタンス化します。クライアントは、依存性注入またはJNDIルックアップを使用してEJB 3.0セッションBeanをインスタンス化します。詳細は、「EJB 3.0サポート」を参照してください。

表1-2に、EJB 3.0 Enterprise Beanの開発時に作成する構成要素をリストします。

表1-2    EJB 3.0 EJBの構成要素 
構成要素  タイプ  説明 

ホーム・インタフェース 

POJI 

@Homeアノテーションが付けられたオプションのPOJIであり、コンテナ自体が実装するオブジェクト、つまりホーム・オブジェクトを指定します。@Homeは、EJB 3.0 Beanが必要に応じてEJB 2.1クライアントと相互運用するのを支援するためにのみ用意されています。ほとんどのEJB 3.0 Beanインスタンスでは、ホーム・インタフェースを提供する必要はありません。 

コンポーネント・インタフェース 

POJI 

@Remoteまたは@Local（デフォルト）のアノテーションが付けられた必須のPOJIであり、Beanに実装してクライアントから起動できるビジネス・メソッドを指定します。デフォルトのコンテナ動作をオーバーライドする必要がないかぎり、他のコンテナ・サービス・メソッドを実装する必要はありません。Beanクラスでは、このインタフェースを実装する必要はありません。 

Beanの実装 

POJO 

コンポーネント・インタフェースをオプションで実装でき、オプションのホーム・インタフェースおよびコンポーネント・インタフェース（ビジネス・メソッド）で定義されたメソッドを実装するJavaコードを含む必須のPOJOです。必要に応じて、コンテナ・ライフ・サイクル・コールバック関数として機能するよう任意のメソッドにアノテーションを付けることができます。 

デプロイメント・ディスクリプタ 

ejb-jar.xml

orion-ejb-jar.xml

toplink-ejb-jar.xml

ejb3-toplink-sessions.xml

persistence.xml

orm.xml 

デプロイのためにBeanの属性を指定するオプションの手段。これらにより、環境、インタフェース名、トランザクションのサポート、EJBのタイプ、および永続性情報など、構成の詳細を決定します。このメタデータはアノテーション（またはデフォルト）によって完全に表現できるため、デプロイメント・ディスクリプタXMLファイルはEJB 3.0では重要性が高くありません。デプロイメント・ディスクリプタXMLファイル内の構成により、対応するアノテーション構成がオーバーライドされます（存在する場合）。詳細は、「EJBデプロイメント・ディスクリプタ・ファイルについて」を参照してください。 

図1-1に示すように、EJB 3.0 EJBインスタンスを取得するために、Webクライアント（サーブレットなど）またはJavaクライアントはJNDIを使用しますが、EJBクライアントはJNDIまたはリソース・インジェクションを使用できます。EJBクライアントの詳細は、「使用しているクライアントのタイプ」を参照してください。

エンティティBeanの場合、EJB 3.0はJPAエンティティの作成、検索、マージおよび維持に使用するEntityManagerを提供します（「JPAエンティティの問合せ方法」を参照）。

図1-1    コンポーネント・インタフェースによるEJB 3.0ステートフル・セッションBeanを使用したクライアント


画像の説明

図1-1のクライアントは、EJBに次のようにアクセスします。

  1. クライアントは、Beanのコンポーネント・インタフェースを取得します。

    サーブレットまたはJavaクライアントは、JNDIを使用してCartのインスタンスをルックアップします。

    EJBクライアントは、Cartインスタンス変数に@EJBアノテーションを付けることによりリソース・インジェクションを使用します。実行時、EJBコンテナにより変数が適宜初期化されます。

    どちらの場合も、EJBコンテナがインスタンス化を管理します。ホーム・インタフェースは不要です。

  2. クライアントは、コンポーネント・インタフェース（リモートまたはローカル・インタフェース）で定義されているメソッドを起動し、これにより、メソッド・コールがBeanインスタンス内の対応するメソッドに（スタブを通じて）委任されます。

  3. クライアントは、コンポーネント・インタフェース内で、@Removeアノテーションが付けられたBeanインスタンス内のメソッドを起動することにより、ステートフル・セッションBeanインスタンスを破棄できます。

    ステートレス・セッションBeanには、removeメソッドは不要です。コンテナが必要に応じてBeanを削除します。コンテナは、構成されたタイムアウトを超えるステートフル・セッションBeanを削除するか、最大の構成済プール・サイズを維持できます。エンティティには、removeメソッドは不要です。EJB 3.0 EntityManagerを使用してエンティティを作成および破棄します。

EJB 2.1 Enterprise Beanの構造

EJB 2.1を使用している場合、EJB実装のインタフェースはEJBのタイプに基づきます。たとえば、EJB 2.1エンティティBeanの実装では、javax.ejb.EntityBeanインタフェースを実装し、EJBHomeまたはEJBLocalHome、およびEJBObjectまたはEJBLocalObjectを拡張する別のインタフェースを指定する必要があります。クライアントは、EJBホーム・インタフェースが提供するcreateメソッドでのみEJB 2.1 Enterprise Beanインスタンスをインスタンス化できます。詳細は、「EJB 2.1サポート」を参照してください。

表1-3に、EJB 2.1 Enterprise Beanの開発時に作成する構成要素をリストします。

表1-3    EJB 2.1 EJBの構成要素 
構成要素  タイプ  説明 

ホーム・インタフェース 

javax.ejb.EJBHome（リモート）

javax.ejb.EJBLocalHome 

コンテナ自体が実装するオブジェクト、つまりホーム・オブジェクトのインタフェースを指定します。ホーム・インタフェースには、Beanの作成方法を指定するcreateメソッドなどのライフ・サイクル・メソッドが含まれています。 

コンポーネント・インタフェース 

javax.ejb.EJBObject（リモート）

javax.ejb.EJBLocalObject 

Beanで実装するビジネス・メソッドを指定します。また、Beanに、その他のコンテナ・サービス・メソッドも実装する必要があります。EJBコンテナは、Beanのライフ・サイクル中に様々なタイミングで、これらのメソッドを起動します。  

Beanの実装 

javax.ejb.SessionBean

javax.ejb.EntityBean

javax.ejb.MessageDrivenBean 

ホーム・インタフェースで定義されるメソッド（ライフ・サイクル・メソッド）、コンポーネント・インタフェースで定義されるメソッド（ビジネス・メソッド）、および必須のコンテナ・メソッド（コンテナ・コールバック関数）を実装するJavaコードが含まれています。 

デプロイメント・ディスクリプタ 

ejb-jar.xml

toplink-ejb-jar.xml

orion-ejb-jar.xml 

デプロイする際のBeanの属性を指定します。これらにより、環境、インタフェース名、トランザクションのサポート、EJBのタイプ、および永続性情報など、構成の詳細を決定します。 

図1-2に示すように、クライアントは、ホーム・インタフェースを使用してEJB 2.1 Enterprise Beanインスタンスを取得し、コンポーネント・インタフェースを使用してビジネス・メソッドを起動します。EJBクライアントの詳細は、「使用しているクライアントのタイプ」を参照してください。

図1-2    ホーム・インタフェースおよびコンポーネント・インタフェースによるEJB 2.1ステートレス・セッションBeanを使用したクライアント


画像の説明

図1-2のクライアントは、EJBに次のようにアクセスします。

  1. クライアントは、Beanのホーム・インタフェースを通常はJNDIを通じて取得します。

  2. クライアントは、ホーム・インタフェースの参照（ホーム・オブジェクト）でcreateメソッドを起動します。これにより、Beanインスタンスが作成され、Beanのコンポーネント・インタフェース（リモートまたはローカル・インタフェース）への参照が返されます。

  3. クライアントは、コンポーネント・インタフェース（リモートまたはローカル・インタフェース）で定義されているメソッドを起動し、これにより、メソッド・コールがBeanインスタンス内の対応するメソッドに（スタブを通じて）委任されます。

  4. クライアントは、コンポーネント・インタフェース（リモートまたはローカル・インタフェース）で定義されているremoveメソッドを起動することにより、Beanのインスタンスを破棄できます。

    ステートレス・セッションBeanなどの一部のBeanでは、removeメソッドをコールしても何も行われません。この場合は、コンテナがBeanインスタンスの削除を行います。

Enterprise Beanのライフ・サイクル

Enterprise Beanのライフ・サイクルには、作成、非アクティブ化、アクティブ化、削除などの重要イベントが関係します。

このような各イベントは、コールバック・メソッドに関連付けられています。ライフ・サイクル・コールバック・メソッドは、次のクラスで定義できます。

これらのオプションを組み合せて使用できます。たとえば、一部のライフ・サイクル・コールバックをセッションBeanクラスのメソッドとして定義し、一部をそのセッションBeanに関連付けられたインターセプタ・クラスに定義できます。

コンテナは、（イベント・タイプに応じて）ライフ・サイクル・イベントの前または直後にコールバックを起動します。

Enterprise Beanに関連付けられているライフ・サイクル・イベント、およびコンテナとBeanプロバイダのどちらがコールバックの実装を行うかは、（適切なEJBインタフェースで指定された）開発しているEnterprise Beanのタイプによって決まります。

EJB 3.0 Enterprise Beanでは、コンテナがライフ・サイクル・コールバックを行う場合は、追加ロジックを実行しないかぎりBeanに実装を提供する必要はありません。

EJB 2.1 Enterprise Beanでは、コンテナがライフ・サイクル・コールバックを行う場合、また追加ロジックを実行しない場合でも、少なくともライフ・サイクルの空の実装を用意して、該当するEJBインタフェースの要件を満たす必要があります。

詳細は、次を参照してください。

Beanクラスのライフ・サイクル・コールバック・メソッド

EJB 3.0 Enterprise Beanタイプの場合は、オプションで任意のEJBクラス・メソッドにライフ・サイクル・メソッドとしてアノテーションを付けることができます。

EJB 2.1 Enterprise Beanの場合は、少なくともライフ・サイクル・メソッドの空の実装を用意して、該当するEJBインタフェースの要件を満たす必要があります。

EJB 3.0インターセプタ・クラスのライフ・サイクル・コールバック・インターセプタ・メソッド

EJB 3.0セッションBeanまたはメッセージドリブンBeanの場合は、オプションでBeanクラスをインターセプタ・クラスに関連付け、任意のインターセプタ・クラス・メソッドにライフ・サイクル・メソッドとしてアノテーションを付けることができます。

詳細は、次を参照してください。

JPAエンティティ・リスナー・クラスのライフ・サイクル・コールバック・リスナー・メソッド

JPAエンティティの場合は、Beanクラスをエンティティ・リスナー・クラスに関連付け、任意のエンティティ・リスナー・クラス・メソッドにライフ・サイクル・メソッドとしてアノテーションを付けることができます。

詳細は、「JPAエンティティのエンティティ・リスナー・クラスのライフ・サイクル・コールバック・リスナー・メソッドの構成」を参照してください。

EJBコンテキストとは

EJBContextインタフェースは、EJB 2.1 Enterprise Beanインスタンスのコンテナ提供ランタイム・コンテキストへのアクセス権をインスタンスに提供します。このインタフェースは、エンタープライズ・インタフェースBeanタイプに固有の追加メソッドを提供するためにSessionContext、EntityContextおよびMessageDrivenContextインタフェースにより拡張されます。

javax.ejb.EJBContextインタフェースの定義は次のとおりです。

public interface EJBContext {
    public EJBHome         getEJBHome(); 
    public Properties      getEnvironment();
    public Principal       getCallerPrincipal();
    public boolean         isCallerInRole(String roleName);
    public UserTransaction getUserTransaction();
    public boolean         getRollbackOnly();
    public void            setRollbackOnly();
}

Beanは、表1-4に示された操作を実行する際、EJBコンテキストを必要とします。

表1-4    EJB 2.1 EJBContextの動作 
メソッド  説明 

getEnvironment 

Beanのプロパティの値を取得します。 

getUserTransaction 

トランザクション・コンテキストを取得します。これにより、Bean管理のトランザクション（BMT）の使用時にプログラムによるトランザクション境界が有効になります。これは、トランザクション対応のBeanでのみ有効です。 

setRollbackOnly 

現在のトランザクションをコミットできないよう設定します。コンテナ管理トランザクションにのみ適用されます。 

getRollbackOnly 

現在のトランザクションがロールバック専用に指定されているかどうかを調べます。コンテナ管理トランザクションにのみ適用されます。 

getEJBHome 

Beanの対応するEJBHome（ホーム・インタフェース）のオブジェクト参照を取得します。 

lookup 

JNDIを使用して、環境変数名でBeanを取得します。このメソッドを使用している場合は、Bean参照に接頭辞"java:comp/env"を付けないでください。 

EJBContextをIntialContextと混同しないようにしてください（「初期コンテキスト・ファクトリの構成」を参照）。

詳細は、次を参照してください。

アノテーションおよびリソース・インジェクションの動作

アノテーションにより、アプリケーションの動作とデプロイを制御できます。メタデータ・アノテーションを使用して、コンテナ動作の適切な要件の指定、サービスやリソースの注入のリクエスト、およびオブジェクト・リレーショナル・マッピングの指定を行うことができます。

アノテーションを使用すると、EJB 3.0 Enterprise Beanは依存性注入メカニズムを使用して、環境内のリソースまたはその他のオブジェクトへの参照を取得できます。たとえば、次のアノテーションを使用できます。

EJB 3.0 Enterprise Beanが依存性注入を利用している場合、OC4JはBeanインスタンスの作成後、ビジネス・メソッドが起動される前にこれらの参照を注入します。

EJBコンテキストに対する依存性が宣言されている場合は、EJBコンテキストも注入されます（「EJBコンテキストとは」を参照）。

依存性注入に失敗した場合、OC4JはBeanインスタンスを破棄します。

OC4Jでは、アノテーションの継承がサポートされます（「アノテーションおよび継承」を参照）。

このリリースでは、Web層でアノテーションおよびリソース・インジェクションを使用できます（「Web層でのアノテーション」を参照）。

アノテーションは、XMLを使用せずに環境参照を指定する別の方法です。フィールドまたはプロパティにアノテーションを付ける場合、コンテナはJNDIからルックアップすることでユーザーにかわって値をBeanに注入します。参照がアノテーションを使用して指定されている場合でも、JNDIを使用してルックアップできます。例1-1に、アノテーションとJNDIの関連を示します。この例のアノテーションは、例1-2にある同等のejb-jar.xmlファイルに対応しています。かわりにこのXMLとJNDIが使用された場合も、コードの動作はまったく同じです。

アノテーション構成は、デプロイXMLを使用してオーバーライドできます（「デプロイメント・ディスクリプタ・エントリによるアノテーションのオーバーライド」を参照）。

例1-1    アノテーションおよびリソース・インジェクションの使用方法

@Stateless
@EJB(name="bean1", businessInterface=Bean1.class)
public class MyBean {
    @EJB Bean2 bean2;

    public void doSomething() {
        // Bean2 is already injected and available
        bean2.foo();
        // or it can be looked up from JNDI
        ((Bean2)(new InitialContext().lookup("java:comp/env/bean2"))).foo();
        // Bean1 has not been injected and is only available through JNDI
        ((Bean1)(new InitialContext().lookup("java:comp/env/bean1"))).foo();
    }
}



例1-2    同等のejb-jar.xmlファイル構成

<ejb-local-ref>
    <ejb-ref-name>bean1</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local>Bean1.class</local>
</ejb-local-ref>

<ejb-local-ref>
    <ejb-ref-name>bean2</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local>Bean2.class</local>
    <injection-target>
        <injection-target-name>bean2</injection-target-name>
    </injection-target>
</ejb-local-ref>

Web層でのアノテーション

このリリースでは、OC4JによりWeb層でのアノテーションおよびリソース・インジェクションがサポートされます。Web層でアノテーションおよびリソース・インジェクションを使用するには、クライアントでJava SE 1.5およびServlet 2.5以上を使用している必要があります。

Web層では、次のアノテーションを使用できます。

詳細は、次を参照してください。

アノテーションおよび継承

アノテーションは、継承に含まれます。アノテーションをホスト・クラスに対してローカルに機能させるには、次の点を考慮してください。

クラス・メンバーに影響しているアノテーションを検出するには、クラス・メンバーの最後の公開宣言または非オーバーライド宣言を追跡調査する必要があります。アノテーションを検出できない場合、エンクロージング・クラス宣言を調査する必要があります。これに失敗しても、他のソース・ファイルは調査しないでください。

表1-5に、アノテーションをリストし、各アノテーションがBeanクラスの継承に関してどのように動作するかを示します。

表1-5    アノテーションおよび継承 
アノテーション  継承の影響  コメント  OC4Jサポート 

@Stateless

@Stateful

@MessageDriven 

スーパークラスのアノテーションは無視されます。

例: 

@Stateful 
class Base {}

@Stateless 
class A extends Base {}

class B extends Base {}

この場合:

- Bean Baseはステートフル・セッションBeanです。

- Bean Aはステートレス・セッションBeanです。親Bean Baseの@Statefulアノテーションは適用されません（無視されます）。

- Bean BはPOJOクラスです。親Bean Baseの@Statefulアノテーションは適用されません（無視されます）。 

クラス・アノテーションまたはデプロイメント・ディスクリプタXMLファイルを通じてBeanクラスを明示的に定義する必要があります。これは、そのBeanが別のBeanクラスのサブクラスである場合でも同様です。 

サポートされます。

OC4Jでは、スーパークラス・レベルのBeanタイプのアノテーションは無視されます。 

@Local

@Remote

@LocalHome

@Home 

スーパークラスのアノテーションは無視されます。

実行時の問題を回避するため、アノテーションを適切に定義する必要があります。

例: 

@Local 
interface Base {}

@Remote 
interface A extends Base {}

interface B extends Base {}

この場合:

- Baseはローカル・ビジネス・インタフェースです。

- Aはリモート・インタフェースです。親Bean Baseの@Localアノテーションは適用されません（無視されます）。

- BはPOJOインタフェースです。親Bean Baseの@Localアノテーションは適用されません（無視されます）。 

Beanに対するアノテーションの動作も同様です。

例: 

@Stateful 
@Local(I1.class)
class A {}

@Stateful 
class B extends A {}

 

注意:Aとは異なり、Bean BはI1ビジネス・インタフェースを持ちません。 

サポートされます。

OC4Jでは、スーパークラス・レベルのBeanタイプのアノテーションは無視されます。 

@TransactionManagement(TransactionManagementType.
CONTAINER)

@TransactionManagement(TransactionManagementType.
APPLICATION) 

スーパークラスのアノテーションは無視されます。

例: 

@ TransactionManagement 
(type=TransactionManagementType.
CONTAINER)
class Base {}

@ TransactionManagement 
(type=TransactionManagementType.
APPLICATION)
class A extends Base {}

class B extends Base {}

この場合:

- Aは、Bean管理のトランザクションを使用するBeanです。

- Bは、デフォルトのコンテナ管理のトランザクションを使用するBeanです。 

クラス・レベルのトランザクション管理を継承しない場合、Bean管理のトランザクションおよびコンテナ管理のトランザクションを使用するBeanがアプリケーション内で混在します。これにより、実行時に問題が発生する可能性があります。

明示的なアノテーションが存在しない場合、Beanではデフォルトでコンテナ管理のトランザクションが使用されます。  

サポートされます。

OC4Jでは、スーパークラス・レベルのBeanタイプのアノテーションは無視されます。 

@TransactionAttribute(TransactionAttributeType.
REQUIRED) {MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER} 

メソッド・レベルの継承と、仮想メソッド・アノテーションの継承が許可されます。

例: 

@Transaction(REQUIRED)
class Base {
    @Transaction(NONE)
    public void foo() {...}
    public void bar() {...}
}

class A extends Base {
    public void foo() {...}
}

public class B extends Base {
    @Transaction(NEW)
    public void foo() {...}
}

@Transaction(NEW)
public class C extends Base {
    public void foo() {...}
    public void bar() {...}
}

@Transaction(NEW)
public class D extends Base {
    public void bar() {...}
}

@Transaction(NEW)
public class E extends Base {

この場合:

- Bean Aにおいて、fooメソッドにはアノテーションがありません。Bean Aは、親Bean Baseのfooメソッドをアノテーションなしでオーバーライドします。したがって、Bean Aのfooメソッドは、@Transaction(NONE)アノテーションを継承しません。

- Bean Bにおいて、@Transaction(NEW)アノテーションは、fooメソッドに適用されます。Bean Bは、親Bean Baseのfooメソッドを@Transaction(NEW)アノテーション付きでオーバーライドします。その結果、Bean Baseのfooメソッドの@Transaction(NONE)アノテーションは、子Bean Bでオーバーライドされるメソッドに適用されません。

- Bean Cにおいて、@Transaction(NEW)アノテーションは、fooメソッドに適用されます。Bean Cは、親Bean Baseのfooメソッドをアノテーションなしでオーバーライドします。したがって、Bean Cのfooメソッドは、@Transaction(NONE)アノテーションを継承しません。ただし、Bean Cは、fooメソッドに適用されるクラス・レベルのアノテーションの@Transaction(NEW)を持ちます。

- Bean Dにおいて、@Transaction(NEW)アノテーションは、barメソッドに適用されます。Bean Dは、親Bean Baseのbarメソッドをアノテーションなしでオーバーライドします。したがって、Bean Dのbarメソッドは、@Transaction(NONE)アノテーションを継承しません。ただし、Bean Dは、barメソッドに適用されるクラス・レベルのアノテーションの@Transaction(NEW)を持ちます。 

スーパーコール・クラス・レベルでアノテーションが付けられ、クラス内のすべてのメソッドに適用される仮想メソッド・アノテーションがサポートされます。

詳細は、http://jcp.org/en/jsr/detail?id=250のJSR 250を参照してください。 

サポートされます。 

@TransactionAttribute(TransactionAttributeType.
REQUIRED) {MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER}

（前行の続き） 

（前行の続き）

- Bean Eにおいて、@Transaction(REQUIRED)アノテーションは、barメソッドに適用されます。Bean Eは、クラス・レベルのアノテーションの@Transaction(NEW)を持ちますが、親Bean Baseのbarメソッドはオーバーライドしません。したがって、Bean Eのbarメソッドは、親Bean Baseからクラス・レベルの@Transaction(REQUIRED)アノテーションを継承します。 

（前行の続き） 

（前行の続き） 

@EJB

@EJBs 

このアノテーションのすべての使用を検出するため、すべてのスーパークラスが調査されます。これには、プライベート・メソッドおよびフィールドと、オーバーライドされたプライベート・メソッド（親と子の両方のプライベート）が含まれます。

例: 

@EJB(beanName = "Bean1"…)
public class Base {
    @EJB(beanName =" Bean2"..)
    private Bean2 b2;
    @EJB(beanName =" Bean3"..)
    protected void setB3(Bean3 b3){}
}

@EJB(beanName = "Bean4"…)
public class A extends Base {
    @EJB(beanName =" Bean5"..)
    private Bean5 b5;
}

public class B extends Base {}

 

Bean Aの解析時には、Bean1、Bean2、Bean3、Bean4およびBean5を含むスーパークラスで定義されているすべての@EJB参照が解析および追加されます。アノテーション付きのフィールドおよびメソッドも注入されます。

Bean Bの解析時には、Bean1、Bean2、Bean3およびBean4を含むスーパークラスで定義されているすべての@EJB参照が解析および追加されます。アノテーション付きのフィールドおよびメソッドも注入されます。 

 

サポートされます。 

@PersistenceUnit

@PersistenceUnits

@PersistenceContext

@PersistenceContexts

 

@EJBおよび@EJBsと同様です（前述の行を参照）。 

 

サポートされます。 

@Resources

@Resource

 

@EJBおよび@EJBsと同様です（前述の行を参照）。 

 

サポートされます。 

@Interceptors

@ExcludeDefaultInterceptor

@ExcludeClassInterceptor 

継承が許可されます。

デフォルト・インターセプタとBeanクラス（およびそのスーパークラス）に定義されたインターセプタ以外に、メソッド・レベルのビジネス・メソッド・インターセプタが起動されます。

例:

デフォルト・インターセプタ: D1.class 

@Interceptors({C1.class})
class Base {
    @Interceptors({M1.class})
    public void foo() {...}
    public void bar() {...}
}

@Interceptors({C2.class})
class A extends Base {
    public void foo() {...}
}

@Interceptors({C2.class})
class B extends Base {
    @Interceptors({M2.class})
    public void foo() {...}
}

@Interceptors({C2.class})
class C extends Base {
    public void bar() {...}
}

@Interceptors({C3.class, C4.class})
class E extends Base {}

@Interceptors({C3.class, C4.class})
class F extends Base {
    @ExcludedDefaultInterceptor
    @ExcludedClassInterceptor
    @Interceptors({M2.class})
    public void bar() {...}
}

この場合:

- Bean Baseのfooメソッドのインターセプタは、D1、C1、M1です。D1はデフォルト・インターセプタであり、C1はBeanクラス・レベルのインターセプタとして、M1はメソッド・レベルのfooのインターセプタとして定義されています。

- Bean Aのfooメソッドのインターセプタは、D1、C2です。D1はデフォルト・インターセプタであり、C1はBeanクラス・レベルのインターセプタとして定義されています。Bean Aは、fooメソッドをオーバーライドし、そのメソッドのメソッド・レベルのインターセプタを定義しません。 

 

サポートされます。 

@Interceptors

@ExcludeDefaultInterceptor

@ExcludeClassInterceptor

（前行の続き）

 

（前行の続き）

- Bean Bのfooメソッドのインターセプタは、D1、C2、M2です。D1はデフォルト・インターセプタであり、C2はBeanクラス・レベルのインターセプタとして定義されています。Bean Bは、fooメソッドをオーバーライドし、メソッド・レベルのインターセプタとしてM2を定義します。

- Bean Cのbarメソッドのインターセプタは、D1、C2です。D1はデフォルト・インターセプタであり、C2はBeanクラス・レベルのインターセプタとして定義されています。

- Bean Eのbarメソッドのインターセプタは、D1、C1です。D1はデフォルト・インターセプタです。Bean Eは、クラス・レベルのアノテーションの@Interceptors({C3.class, C4.class})を持ちますが、親Bean Baseのbarメソッドはオーバーライドしません。したがって、Bean Eのbarメソッドは、親Bean Baseからクラス・レベルの@Interceptors({C1.class})アノテーションを継承します。

- Bean Fのbarメソッドのインターセプタは、M2です。barに@ExcludeDefaultInterceptorというアノテーションが付けられているため、デフォルト・インターセプタのD1はこのメソッドに適用されません。barには@ExcludeClassInterceptorというアノテーションも付けられているため、クラス・レベルで定義されたインターセプタも適用されません。Bean Fは、barメソッドをオーバーライドし、それに@Interceptors({M2.class})アノテーションを付けます（このアノテーションのみが適用されます）。 

（前行の続き） 

（前行の続き） 

@AroundInvoke 

Beanクラスにスーパークラスがある場合、@AroundInvokeアノテーション付きでそれらのスーパークラスに定義されたメソッドが起動されます（最も一般的なスーパークラスのメソッドが最初に起動されます）。

例: 

class Base {
    @AroundInvoke
    public Object
 foo(InvocationContext cts) {...}
}

class A extends Base {
    @AroundInvoke
    public Object
 bar(InvocationContext cts) {...}
}

class B extends Base {
    public Object
 foo(InvocationContext cts) {...}
}

この場合:

- Bean Baseにおいて、インターセプタ・メソッドはfoo()です。

- Bean Aには、fooおよびbarの2つのインターセプタ・メソッドがあります。barメソッドはBean Aで定義されており、fooメソッドは親Bean BaseからBean Aに継承されています。最初にfooが起動され、次にbarが起動されます。

- Bean Bには、インターセプタ・メソッドはありません。Bean Bは、@AroundInvokeアノテーションなしでfooメソッドをオーバーライドするため、このメソッドはインターセプタ・メソッドではなくなります。  

インターセプタ・クラスにスーパークラスがある場合、インターセプタ・クラスのスーパークラスで定義されたインターセプタ・メソッドは、インターセプタ・クラスで定義されたインターセプタ・メソッドの前に起動されます（最も一般的なスーパークラスのメソッドが最初に起動されます）。 

サポートされます。 

@PostConstruct

@PreDestroy

@PostActivate

@PrePessivate 

Beanクラスにスーパークラスがある場合、それらのスーパークラスに定義されたライフ・サイクル・コールバック（インターセプタ）メソッドが起動されます（最も一般的なスーパークラスのメソッドが最初に起動されます）。

注意:オーバーライドされたライフ・サイクル・メソッドは起動されません。

例: 

class Base {
    @PostConstruct
    @PostActivate
    void foo() {...}
}

class A extends Base {
    @PostConstruct
    void bar() {...}
    @PostActivate
    void ping() {...}
}

class B extends Base {
    @PreDestroy
    void foo() {...}
}

class C extends Base {
    ejbCreate() {...}
}

class D extends Base {
    @PostConstruct
    ping() {...}
    ejbCreate() {...}
}

この場合:

- Bean Baseには、post-constructメソッドのfooおよびpost-activateライフ・サイクル・メソッドのfooの2つのライフ・サイクル・メソッドがあります。

- Bean Aには、fooおよびbarの2つのpost-constructメソッドがあります。最初にfooメソッドが起動され、次にbarが起動されます。また、Bean Aには、fooおよびpingの2つのpost-activateライフ・サイクル・メソッドがあります。最初にfooメソッドが起動され、次にpingが起動されます。

- Bean Bにおいて、fooメソッドは@PreDestroyアノテーション付きでオーバーライドされています。したがって、post-constructメソッドはBean Bで定義されず、post-activateライフ・サイクル・メソッドも定義されません。Bean Bで定義されるのは、pre-destroyライフ・サイクル・メソッドのfooのみです。

- Bean Cには、親Bean Baseから継承されて最初に起動されるfooと、Bean Cで定義されて2番目に起動されるejbCreateの2つのpost-constructメソッドがあります。

- Bean Dではエラーが発生します。EJB 2.1スタイルのライフ・サイクル・コールバック（ejbCreate()メソッドなど）は、対応するEJB 3.0スタイル（@PostConstructアノテーションなど）のコールバックと1つのBeanクラス内で共存できません。 

インターセプタ・クラスにスーパークラスがある場合、インターセプタ・クラスのスーパークラスで定義されたライフ・サイクル・コールバック・インターセプタ・メソッドは、インターセプタ・クラスで定義されたライフ・サイクル・コールバック・インターセプタ・メソッドの前に起動されます（最も一般的なスーパークラスのメソッドが最初に起動されます）。 

サポートされます。 

@Timeout 

継承階層で最大1つのタイムアウト・メソッドが許可されます。

例: 

class Base {
    @Timeout
    public void
 foo(Timer) {...}
}

class A extends Base {
    @Timeout
    public void
 bar(Timer) {...}
}

class B extends Base {
    public void
 foo(Timer) {...}
}

class C extends Base implements
 TimedObject {
    public void
 ejbTimeout(Timer) {...}
}

この場合:

- fooは、Bean Baseのタイムアウト・メソッドです。

- Bean Aではエラーが発生します。barは、Bean Aで定義されているタイムアウト・メソッドです。Bean Aは、親Bean Baseからもfooタイムアウト・メソッドを継承しています。この場合、Bean Aに2つのタイムアウト・メソッドが存在することになりますが、これは許可されません。

- Bean Bには、タイムアウト・メソッドが存在しません。Bean Bは、アノテーションなしでfooメソッドをオーバーライドするため、タイムアウト・メソッドはなくなります。

- Bean Cではエラーが発生します。ejbTimeoutは、Bean Cで定義されているタイムアウト・メソッドです。また、Bean Cは、親Bean Baseからfooタイムアウト・メソッドを継承しています。この場合、Bean Cに2つのタイムアウト・メソッドが存在することになりますが、Bean Cに2つのタイムアウト・メソッドが存在することは許可されません。 

ベースおよびスーパークラスの両方でメソッドにアノテーションが付けられている場合（異なるメソッド名）、EJB 3.0仕様ではBeanごとに1つのタイムアウト・メソッドのみ許可されるため、コンテナから例外がスローされます。 

サポートされます。 

@Remove 

複数の削除が許可されます。

例: 

class Base {
    @Remove
    void foo() {...}
}

class A extends Base {
    @Remove
    void bar() {...}
}

class B extends Base {
    void foo() {...}
}

class C extends Base {
    @Remove
    void foo(int) {...}
}

この場合:

- fooは、Bean Baseの削除メソッドです。

- fooおよびbarは、Bean Aの削除メソッドです。barメソッドは、Bean Aで削除メソッドとして明示的に定義されています。Bean Aは、fooメソッドをオーバーライドしないため、親Bean Baseから削除メソッドとしてfooを継承します。

- Bean Bには、削除メソッドはありません。Bean Bは、アノテーションなしでfooメソッドをオーバーライドします（メソッドがオーバーライドされなければ、Bean Baseのfooメソッドの@Removeアノテーションが継承されます）。

- foo()およびfoo(int)は、Bean Cの削除メソッドです。foo(int)メソッドは、Bean Cで削除メソッドとして明示的に定義されています。Bean Cは、foo()メソッドをオーバーライドしないため、親Bean Baseから削除メソッドとしてfoo()を継承します。 

@Removeアノテーションは、本質的に付加的です。1つのBean内で複数の削除メソッドが許可されます。 

サポートされます。 

@RolesAllowed

@DenyAll

@PermitAll

 

メソッド・レベルの継承のみ許可されます。

例: 

@PermitAll
class Base {
    @DenyAll
    public void foo() {...}
    void bar() {...}
}

class A extends Base {
    public void foo() {...}
}

public class B extends Base {
    @RolesAllowed({admin})
    public void foo( ) {...}
}

@RolesAllowed({guest}, {admin})
public class C extends Base {
    public void foo() {...}
    void bar(){...}
}

@DenyAll
public class D extends Base {
    public void bar() {...}
}

@RolesAllowed({guest}, {admin})
public class E extends Base {}

@RolesAllowed({guest}, {admin})
class F extends Base {
    @RolesAllowed ({admin})
    public void bar() {...}
}

この場合:

- Bean Aにおいて、セキュリティ権限はfooメソッドに付与されません（どのロールも許可されません）。Bean Aは、親クラスBaseからクラス・レベルのアノテーションを継承できません。さらに、Bean Aは、その親のfooメソッドをオーバーライドし、そのオーバーライド後のメソッドにアノテーションを付けないため、Bean Aのfooメソッドは、アノテーションなしのメソッドとして動作します。

- Bean Bにおいて、fooメソッドではadminロールのみが許可されます。Bean Bは、独自のクラス・レベルのアノテーションを持たず、親クラスBaseからもクラス・レベルのアノテーションを継承しません。ただし、Bean Bは、その親のfooメソッドをオーバーライドし、そのオーバーライド後のメソッドに@RolesAllowed({admin})アノテーションを付けるため、Bean Bのfooメソッドでは、adminロールが設定されます。 

これは、トランザクション属性の使用例と同様です。

注意:EJB 3.0仕様には、メソッド・レベルのセキュリティ・アノテーションがクラス・レベルのアノテーションをオーバーライドすると記載されています。ただし、ejb-jar.xmlのmethod-permission要素では、この設定は付加的（またはクラス・レベルとメソッド・レベル両方のロールの組合せ）となります。この例は、Bean Fの場合です。  

サポートされます。 

@RolesAllowed

@DenyAll

@PermitAll

（前行の続き） 

（前行の続き）

- Bean Cにおいて、fooメソッドではguestおよびadminロールが許可されます。Bean Cは、@RolesAllowed({guest},{admin})という独自のクラス・レベルのアノテーションを持ちますが、親クラスBaseからクラス・レベルのアノテーションを継承しません。Bean Cは、その親のfooメソッドをオーバーライドし、そのオーバーライド後のメソッドにアノテーションを付けないため、Bean Cのfooメソッドでは、guestおよびadminロールが設定されます。

- Bean Dにおいて、barメソッドではどのロールも許可されません（すべて拒否）。Bean Dは、@DenyAllという独自のクラス・レベルのアノテーションを持ちますが、親クラスBaseからクラス・レベルのアノテーションを継承しません。Bean Dは、その親のbarメソッドをオーバーライドし、そのオーバーライド後のメソッドにアノテーションを付けないため、Bean Dのbarメソッドでは、すべてのセキュリティ権限が拒否されます。

- Bean Eにおいて、barメソッドではすべてのロールが許可されます（すべて許可）。Bean Eは、@RolesAllowed({guest},{admin})という独自のクラス・レベルのアノテーションを持ちますが、親クラスBaseからクラス・レベルのアノテーションを継承しません。ただし、Bean Eは、その親のbarメソッドをオーバーライドしないため、Bean Baseから@PermitAllアノテーション付きでこのメソッドを継承します。

- Bean Fの説明は、「コメント」列を参照してください。 

（前行の続き） 

（前行の続き） 

@RunAs 

クラス・レベルの継承は許可されません。

例: 

@RunAs ("bob")
class Base {}

@RunAs ("joe")
class A extends Base {}

class B extends Base {}

この場合:

- 実行者は、Bean Aではjoeとして定義されます。Bean Aは、親クラスからアノテーションを継承できないため、親クラスBaseから実行者bobを継承しません。

- 実行者は、Bean Bでは定義されません。Bean Bは、親クラスからアノテーションを継承できないため、親クラスBaseからロールbobを継承しません。 

 

サポートされます。

スーパークラス・レベルのBeanタイプのアノテーションは無視されます。 

@DeclareRoles 

クラス・レベルの継承は許可されません。

例: 

@DeclareRoles ({"bob"})
class Base {}

@DeclareRoles ({"joe"})
class A extends Base {}

class B extends Base {}

この場合:

- Bean Aは、ロールjoeを宣言しています。Bean Aは、親クラスからアノテーションを継承できないため、親クラスBaseからロールbobを継承しません。

- Bean Bは、ロールを宣言していません。Bean Bは、親クラスからアノテーションを継承できないため、親クラスBaseからロールbobを継承しません。  

 

サポートされます。 

@WebService 

クラス・レベルの継承は許可されません。

例: 

@WebServices
class Base {}

@Stateless
class A extends Base {}

この場合:

- Bean Aは、親クラスBaseから@WebServiceアノテーションを継承しないため、Webサービス・エンドポイントではありません。 

 

サポートされます。

スーパークラス・レベルのBeanタイプのアノテーションは無視されます。 

@StatefulDeployemt

@StatelessDeployemt

@MessageDrivenDeployemt 

クラス・レベルの継承は許可されません。

例: 

@StatefulDeployment (timeout=60)
class Base {}

@StatefulDeployment (timeout=30)
class A extends Base {}

class B extends Base {}

この場合:

- Bean Aには、30のステートフル・デプロイ・タイムアウトが設定されます。Bean Aは、親クラスからアノテーションを継承できないため、親クラスBaseから60のステートフル・デプロイ・タイムアウトを継承しません。

- Bean Bには、タイムアウトが設定されません。Bean Bは、親クラスからアノテーションを継承できないため、親クラスBaseから60のステートフル・デプロイ・タイムアウトを継承しません。 

これらはOC4J固有のアノテーションであり、EJB 3.0仕様には定義されていません。 

サポートされます。

スーパークラス・レベルのBeanタイプのアノテーションは無視されます。 

デプロイメント・ディスクリプタ・エントリによるアノテーションのオーバーライド

アプリケーション設計では、アノテーションとデプロイメント・ディスクリプタの使用を組み合せることができます。この場合、デプロイメント・ディスクリプタは、アノテーションのオーバーライド・メカニズムとして機能します。XMLディスクリプタを使用してアノテーションをオーバーライドするときに適用されるルールのリストは、EJB 3.0仕様を参照してください。

OC4Jでは、EJB 3.0仕様に定義されたアノテーション・オーバーライド・ルールがサポートされます。現在のリリースのOC4Jでは、デプロイメント・ディスクリプタによるオーバーライドがこれらのルールに違反すると、OC4Jにより警告が記録されてそのオーバーライドは無視され、アノテーション構成が使用されます。たとえば、あるクラスに@Statefulアノテーションを付け、次にejb-jar.xmlファイルの<entity>エントリでこの設定をオーバーライドすると、Beanタイプはオーバーライドできないというオーバーライド・ルールに違反します。この場合、OC4Jは、警告を記録してオーバーライドを無視し、そのクラスを引き続きステートフル・セッションBeanとして処理します。

注意

将来のリリースのOC4Jでは、デプロイを中断する例外で警告が置き換えられる予定です。 

表1-6に、EJB 3.0仕様に定義されているXMLによるアノテーションのオーバーライド・ルールと、それらのルールに関するOC4J（リリース10.1.3.1、EJBレイヤー）の動作をリストします。

表1-6    XMLによるアノテーションのオーバーライド 
有効範囲  アノテーション  XML  EJB 3.0仕様のオーバーライド・ルール  OC4J固有の動作（リリース10.1.3.1） 

セッションBeanタイプ 

@Stateless

@Stateful

 

<session-type>

 

EJB 3.0仕様の19.2項には、Beanタイプを@Stateless、@Statefulまたは@MessageDrivenアノテーションで指定している場合、そのタイプはデプロイメント・ディスクリプタでオーバーライドできないと記載されています。Beanタイプ（およびそのセッション・タイプ）を指定する場合、アノテーションでの指定と同じにする必要があります。 

このルールに違反すると、OC4Jにより警告が記録されます。

注意:OC4Jの11gリリースでは、コンテナにより検証例外がスローされる予定です。

 

トランザクション・タイプ: BMTまたはCMT 

@TransactionManagement(TransactionManagementType.
CONTAINER, TransactionManagementType.
APPLICATION) 

<transaction-type>

 

EJB 3.0仕様の13.3.6項には、トランザクション・タイプのオーバーライドは許可されないと記載されています。 

このルールに違反すると、OC4Jにより警告が記録されます。

注意:OC4Jの11gリリースでは、コンテナにより検証例外がスローされる予定です。

 

トランザクション属性 

@TransactionAttribute(TransactionAttributeType.
REQUIRED) {MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER} 

<container-transaction>

<trans-attribute>

 

EJB 3.0仕様の13.3.7項には、トランザクション属性を指定するメタデータ・アノテーションの代替として（またはトランザクション属性のメタデータ・アノテーションを補足またはオーバーライドする手段として）XMLを使用できると記載されています。デプロイメント・ディスクリプタに指定されたトランザクション属性は、アノテーションに指定されたトランザクション属性をオーバーライドまたは補足するとみなされます。  

OC4Jは、このオーバーライド・ルールに準拠しています。

 

インターセプタ 

@Interceptors

@ExcludeDefaultInterceptor

@ExcludeClassInterceptor 

<interceptor-binding>

<exclude-default-interceptors>

<exclude-class-interceptors>

<interceptor-order> 

EJB 3.0仕様の12.8.2項には、クラスへのインターセプタのバインドは付加的であると記載されています。XMLを使用して、アノテーションにより定義されたインターセプタおよびインターセプタ・メソッドを拡張できます。仕様には、インターセプタの起動順序を指定する場合や、メタデータ・アノテーションで指定された順序をオーバーライドする場合にも代替としてXMLを使用できると記載されています。 

OC4Jでは、複数のinterceptor-order定義は許可されません。interceptor-orderを使用する場合、exclude-class-interceptorsおよびexclude-default-interceptorsフラグは無効にできません。また、interceptor-orderの外部ではinterceptor-classを定義できません。これらはEJB 3.0仕様には定義されていません。

 

インターセプタ・コールバック 

@PostConstruct

@PreDestroy

@PostActivate

@PrePessivate

@AroundInvoke 

<post-construct-method>

<pre-destroy-method>

<post-activate-method>

<pre-passivate-method>

<around-invoke-method>

 

EJB 3.0仕様の12.8.1項には、デプロイメント・ディスクリプタを使用してインターセプタを定義しているかどうか、またはアノテーションとデプロイメント・ディスクリプタ要素の組合せを使用しているかどうかにかかわらず、around-invokeメソッド、post-constructメソッド、pre-destroyメソッド、pre-passivateメソッドまたはpost-activateメソッドとして特定のインターセプタ・クラスで指定できるのは、最大で1つのメソッドであると記載されています。 

OC4Jでは、シングルトン制限を検証することなく、ライフ・サイクル・コールバック・メソッドがディスクリプタ・リストに追加されます。 

セキュリティ識別情報 

@DeclareRoles

@RunAs 

<security-role>

<role-name>

 

EJB 3.0仕様の17.3.4項には、XMLの<security-identity>要素を使用して、メタデータに指定されたセキュリティ識別情報をオーバーライドできると記載されています。<security-identity>要素の値は、use-caller-identityまたはrun-asです。 

OC4Jは、このオーバーライド・ルールに準拠しています。  

メソッド許可 

@RolesAllowed

@DenyAll

@PermitAll

 

<method-permission>

 

EJB 3.0仕様の17.3.2.2項には、メソッド許可を指定するメタデータ・アノテーションの代替として（またはメソッド許可の値のメタデータ・アノテーションを補足またはオーバーライドする手段として）XMLの<method-permission>要素を指定できると記載されています。デプロイメント・ディスクリプタに明示的に指定された値は、アノテーションに指定された任意の値をオーバーライドします。オーバーライドの粒度は、メソッド・レベルです。メソッド許可の関係は、個々の<method-permission>要素に定義されたすべてのメソッド許可の組合せとして定義されます。 

OC4Jは、このオーバーライド・ルールに準拠しています。  

EJB参照 

@EJB

@EJBs

 

<ejb-ref>

<ejb-local-ref>

 

EJB 3.0仕様の16.5.2.1項には、XMLエントリで@EJBまたは@EJBsアノテーションをオーバーライドする場合、次のルールが適用されると記載されています。

  • 関連するデプロイメント・ディスクリプタ・エントリは、（デフォルトの、または明示的に指定された）アノテーションとともに使用されるJNDI名に基づいて配置します。

  • <remote>、<local>、<remote-home>または<local-home>要素を使用してデプロイメント・ディスクリプタに指定されるタイプと、<ejb-link>要素で参照されるBeanは、フィールドやプロパティのタイプか、または@EJBアノテーションのbeanInterface要素で指定されるタイプに割当て可能である必要があります。

  • descriptionを指定すると、アノテーションのdescription要素がオーバーライドされます。

  • 注入ターゲットを指定する場合、アノテーション付きのフィールドまたはプロパティ・メソッドを正確に指定する必要があります。

 

OC4Jは、このオーバーライド・ルールに準拠しています。  

リソース参照 

@Resource

@Resources

 

<env-entry>

<resource-ref>

<resource-env-ref>

 

EJB 3.0仕様の16.2.3項には、XMLエントリで@Resourceまたは@Resourcesアノテーションをオーバーライドする場合、次のルールが適用されると記載されています。

  • 関連するデプロイメント・ディスクリプタ・エントリは、（デフォルトの、または明示的に指定された）アノテーションとともに使用されるJNDI名に基づいて配置します。

  • デプロイメント・ディスクリプタに指定されるタイプは、フィールドやプロパティのタイプか、または@Resourceアノテーションで指定されるタイプに割当て可能である必要があります。

  • descriptionを指定すると、アノテーションのdescription要素がオーバーライドされます。

  • 注入ターゲットを指定する場合、アノテーション付きのフィールドまたはプロパティ・メソッドを正確に指定する必要があります。

  • <res-sharing-scope>要素を指定すると、アノテーションのshareable要素がオーバーライドされます。

  • <res-auth>要素を指定すると、アノテーションのauthenticationType要素がオーバーライドされます。

 

OC4Jは、このオーバーライド・ルールに準拠しています。 

永続性ユニット 

@PersistenceUnits

@PersistenceUnit 

<persistence-units>

<persistence-unit>

 

EJB 3.0仕様の16.10.2.1項には、XMLエントリで@PersistenceUnitまたは@PersistenceUnitsアノテーションをオーバーライドする場合、次のルールが適用されると記載されています。

  • 関連するデプロイメント・ディスクリプタ・エントリは、（デフォルトの、または明示的に指定された）アノテーションとともに使用されるJNDI名に基づいて配置します。

  • デプロイメント・ディスクリプタの<persistence-unit-name>要素は、アノテーションのunitName要素をオーバーライドします。

  • 注入ターゲットを指定する場合、アノテーション付きのフィールドまたはプロパティ・メソッドを正確に指定する必要があります。

 

OC4Jは、このオーバーライド・ルールに準拠しています。  

永続性コンテキスト 

@PersistenceContext

@PersistenceContexts 

<persistence-context>

<persistence-contexts>

 

EJB 3.0仕様の16.11.2項には、XMLエントリで@PersistenceContextまたは@PersistenceContextsアノテーションをオーバーライドする場合、次のルールが適用されると記載されています。

  • 関連するデプロイメント・ディスクリプタ・エントリは、（デフォルトの、または明示的に指定された）アノテーションとともに使用されるJNDI名に基づいて配置します。

  • デプロイメント・ディスクリプタの<persistence-context-type>要素は、アノテーションのtype要素をオーバーライドします。

  • 任意の<persistence-property>要素は、@PersistenceContextまたは@PersistenceContextsアノテーションで指定された設定に追加されます。指定されたプロパティの名前が@PersistenceContextアノテーションで指定された名前と同じである場合、アノテーションで指定された値はオーバーライドされます。

  • 注入ターゲットを指定する場合、アノテーション付きのフィールドまたはプロパティ・メソッドを正確に指定する必要があります。

 

OC4Jは、このオーバーライド・ルールに準拠しています。  

タイムアウト 

@Timeout 

<timeout-method>

 

EJB 3.0仕様の18.2.2項には、@Timeoutアノテーションが使用される場合、またはBeanにTimedObjectインタフェースが実装される場合、指定した<timeout-method> XMLは、同じメソッドを参照する目的にのみ使用できると記載されています。 

OC4Jは、このオーバーライド・ルールに準拠しています。  

削除 

@Remove (retainIfException=true|false)

 

<remove-method>

<retain-if-exception>

 

EJB 3.0仕様の4.3.11項には、XMLの<remove-method>要素の<retain-if-exception>サブ要素を明示的に指定して、@Removeアノテーションにより指定またはデフォルト設定されたretainIfExceptionの値をオーバーライドできると記載されています。 

OC4Jでは、ステートフル・セッションBeanで削除メソッドが適切に処理されます。 

アクティブ化構成 

@MessageDriven

activationConfig 

<activation-config> 

EJB 3.0仕様の5.4.13項には、デプロイメント・ディスクリプタで指定されたアクティブ化構成プロパティは、@MessageDrivenアノテーションで指定された設定に追加されると記載されています。同じ名前のプロパティが両方で指定されると、アノテーションで指定された値はデプロイメント・ディスクリプタの値でオーバーライドされます。 

OC4Jは、このオーバーライド・ルールに準拠しています。

注意:現在のリリースのOC4Jには不具合があります。コンテナではオーバーライドが実行されない場合があります。かわりに、新規アクティブ化構成オブジェクトがリストに作成されます。

 

デプロイ 

@StatefulDeployemt

@StatelessDeployemt

@MessageDrivenDeployemt 

<session-deployment>

<message-driven-deployment>

 

これらのアノテーションはEJB 3.0仕様には定義されていません。これらはOC4J固有のアノテーションです。 

OC4Jでは、適用時に、XMLのデプロイ設定でアノテーションがオーバーライドされます。 

OC4Jによるアノテーション属性mappedNameのサポート

OC4Jでは、@EJBおよび@ResourceのmappedName属性がサポートされます。これらのアノテーションのmappedNameは、orion-ejb-jar.xmlに含まれるsession-deployment、entity-deploymentおよびmessage-driven-deployment要素のlocation属性と同じものです。

OC4Jでは、@Stateless、@Statefulまたは@MessageDrivenアノテーションのmappedName属性はサポートされません。

セッションBeanとは

セッションBeanは、単一のクライアント/サーバー・セッションの継続時間中、クライアントによって作成されるEJB 3.0またはEJB 2.1 Enterprise Beanコンポーネントです。セッションBeanは、クライアントの操作を実行します。セッションBeanはトランザクション対応ですが、システム障害の発生時にリカバリできません。セッションBeanオブジェクトは、ステートレス（「ステートレス・セッションBeanとは」を参照）またはステートフル（メソッド・コールおよびトランザクション間で対話状態を維持、「ステートフル・セッションBeanとは」を参照）です。セッションBeanが状態を維持する場合、OC4Jは、オブジェクトをメモリーから削除する必要がある場合にこの状態を管理します（「ステートフル・セッションBeanの非アクティブ化が発生する状況」を参照）。ただし、セッションBeanオブジェクトは自身の永続データを管理する必要があります。

クライアントの観点からは、セッションBeanは非永続オブジェクトであり、アプリケーション・サーバーで稼働するいくつかのビジネス・ロジックを実装します。たとえば、オンライン・ストア・アプリケーションでは、セッションBeanを使用して、Cartインタフェースを提供するShoppingCartBeanを実装します。クライアントは、このインタフェースを使用して、purchaseItemやcheckoutなどのメソッドを起動します。

各クライアントには、固有のセッション・オブジェクトが割り当てられます。クライアントはセッションBeanのクラスのインスタンスに直接にはアクセスしません。クライアントは、Beanのホーム（「ホーム・インタフェースの実装」を参照）およびコンポーネント（「コンポーネント・インタフェースの実装」を参照）インタフェースを通じてセッション・オブジェクトにアクセスします。セッションBeanのクライアントは、Beanにより提供されるインタフェースおよびクライアントにより使用されるインタフェースに応じて、ローカル・クライアント、リモート・クライアントまたはWebサービス・クライアント（ステートレス・セッションBeanのみ）となります。

OC4Jは、各セッションBeanインスタンスのセッション・コンテキスト（「セッション・コンテキストとは」を参照）を維持します。このセッション・コンテキストを使用して、コンテナにコールバック・リクエストを行います。

この項の内容は次のとおりです。

詳細は、次を参照してください。

ステートレス・セッションBeanとは

ステートレス・セッションBeanは、対話状態のないセッションBeanです。特定のステートレス・セッションBeanクラスのインスタンスはすべて同一です。

ステートレス・セッションBeanおよびそのクライアントは、メソッド間で状態または識別情報を共有しません。ステートレス・セッションBeanは、1回のみ起動可能なBeanです。特定のクライアントに固有ではない、再利用可能なビジネス・サービスで使用されます。たとえば、一般的な為替換算、ローン金利の計算などに使用されます。ステートレス・セッションBeanには、クライアントから独立した、コール間に渡る読取り専用の状態が格納される場合があります。その後のコールは、プール内の他のステートレス・セッションBeanによって処理されます。情報は、1回の起動中にのみ使用されます。

OC4Jは、複数のクライアントを処理するために、これらのステートレスBeanのプールを維持しています。クライアントがリクエストを送信すると、プールからインスタンスが取得されます。Beanの情報を初期化する必要はありません。

ステートレス・セッションBeanのクライアントは、Webサービス・クライアントである場合があります。Webサービス・クライアント・ビューを提供できるのは、ステートレス・セッションBeanのみです。

詳細は、次を参照してください。

ステートレス・セッションBeanのライフ・サイクル

図1-3に、ステートレス・セッションBeanのライフ・サイクルを示します。@PostConstructなどのアノテーションは、EJB 3.0のステートレス・セッションBeanにのみ適用されます。

図1-3    ステートレス・セッションBeanのライフ・サイクル


画像の説明

EJB 3.0とEJB 2.1のステートレス・セッションBeanのライフ・サイクルは同一です。違いは、ライフ・サイクル・コールバック・メソッドの登録方法です（表1-7および表1-8を参照）。

表1-7に、アノテーションを使用して定義できるEJB 3.0ステートレス・セッションBeanのオプションのライフ・サイクル・コールバック・メソッドをリストします。EJB 3.0ステートレス・セッションBeanでは、これらのメソッドを実装する必要はありません。

表1-7    EJB 3.0ステートレス・セッションBeanのライフ・サイクル・メソッド 
アノテーション  説明 

@PostConstruct 

このオプションのメソッドは、Beanに対して最初のビジネス・メソッドを起動する前に、ステートフル・セッションBeanに対して起動されます。これは、任意の依存性注入がコンテナにより実行された後の時点です。 

@PreDestroy 

このオプションのメソッドは、インスタンスがコンテナにより削除されているときにステートフル・セッションBeanに対して起動されます。通常、インスタンスは保持していたリソースを解放します。 

表1-8に、javax.ejb.SessionBeanインタフェースでの指定に従って、ステートフル・セッションBeanが実装する必要のあるEJB 2.1ライフ・サイクル・メソッドをリストします。EJB 2.1ステートフル・セッションBeanでは、最低でも、すべてのコールバック・メソッド用に空の実装を用意する必要があります。

表1-8    EJB 2.1ステートレス・セッションBeanのライフ・サイクル・メソッド 
EJBメソッド  説明 

ejbCreate 

コンテナは、Beanの作成直前にこのメソッドを起動します。このメソッドを使用して、データソースの取得など、クライアントに固有でない情報を初期化します。 

ejbActivate 

このメソッドは、ステートレス・セッションBeanに対しては決してコールされません。空の実装のみ用意します。 

ejbPassivate 

このメソッドは、ステートレス・セッションBeanに対しては決してコールされません。空の実装のみ用意します。 

ejbRemove 

コンテナは、ステートレス・セッションBeanを破棄する前にこのメソッドを起動します。このメソッドを使用して、データソースなどの外部リソースのクローズなど、必要なクリーンアップを実行します。 

setSessionContext 

コンテナは、Beanを最初にインスタンス化した後にこのメソッドを起動します。このメソッドを使用して、Beanのコンテキストの参照を取得します。詳細は、「setSessionContextメソッドの実装」を参照してください。 

詳細は、次を参照してください。

ステートフル・セッションBeanとは

ステートフル・セッションBeanは、対話状態を維持するセッションBeanです。

ステートフル・セッションBeanは、対話型セッションで使用します。対話型セッションでは、インスタンス変数値やトランザクションの状態などをメソッド間で維持する必要があります。これらのセッションBeanは、単一クライアントの存続期間中、そのクライアントにマッピングされます。

ステートフル・セッションBeanは、メソッド・コール間で状態を維持します。したがって、各クライアントに対し、ステートフル・セッションBeanのインスタンスが1つずつ作成されます。それぞれのステートフル・セッションBeanには、個別のクライアントの識別情報と、1対1のマッピングが含まれています。

コンテナが、（リソースを解放するために）メモリーからステートフル・セッションBeanを削除する必要があると判断した場合、コンテナは非アクティブ化（ディスクへのBeanのシリアライズ）によってBeanの状態を維持します。そのため、非アクティブ化する状態はシリアライズ可能である必要があります。ただし、システム障害が発生した場合、この情報は維持されません。Beanのインスタンスがクライアントによって再びリクエストされると、コンテナは以前に非アクティブ化したBeanインスタンスをアクティブ化します。

保存される状態のタイプには、リソースは含まれません。コンテナによりBean内のejbPassivateメソッドが起動され、Beanがリソースのクリーンアップを行います。これらのリソースには、保持されたソケット、データベース接続、および静的情報が含まれているハッシュテーブルなどがあります。これらのリソースは、すべてejbActivateメソッド中に再割当ておよび再作成可能です。

注意

ステートフル・セッションBeanの非アクティブ化はオフにできます（「非アクティブ化の構成」を参照）。 

Beanのインスタンスでエラーが発生すると、Bean内で継続的に状態を保存するアクションを実行していないかぎり、状態が失われます。ただし、フェイルオーバーに備えて常に状態を保存する必要がある場合、実装にエンティティBeanを使用することをお薦めします。または、SessionSynchronizationインタフェースを使用して、状態をトランザクションによって維持することも可能です。

たとえば、ステートフル・セッションBeanは、ショッピング・カート・オンライン・アプリケーションのサーバー・サイドを実装可能です。このアプリケーションには、購入可能な商品のリストを返し、アイテムを顧客のショッピング・カートに入れ、発注を行い、顧客のプロファイルを変更するなどの作業を行うためのメソッドが含まれます。

詳細は、次を参照してください。

ステートフル・セッションBeanのライフ・サイクル

図1-4に、ステートフル・セッションBeanのライフ・サイクルを示します。@PostConstructなどのアノテーションは、EJB 3.0のステートフル・セッションBeanにのみ適用されます。

図1-4    ステートフル・セッションBeanのライフ・サイクル


画像の説明

EJB 3.0とEJB 2.1のステートフル・セッションBeanのライフ・サイクルは同一です。違いは、ライフ・サイクル・コールバック・メソッドの登録方法です（表1-9および表1-10を参照）。

表1-9に、アノテーションを使用して定義できるEJB 3.0ステートフル・セッションBeanのオプションのライフ・サイクル・コールバック・メソッドをリストします。EJB 3.0ステートフル・セッションBeanでは、これらのメソッドを実装する必要はありません。

表1-9    EJB 3.0ステートフル・セッションBeanのライフ・サイクル・メソッド 
アノテーション  説明 

@PostConstruct 

このオプションのメソッドは、Beanに対して最初のビジネス・メソッドを起動する前に、ステートフル・セッションBeanに対して起動されます。これは、任意の依存性注入がコンテナにより実行された後の時点です。 

@PreDestroy 

このオプションのメソッドは、インスタンスがコンテナにより削除されているときにステートフル・セッションBeanに対して起動されます。通常、インスタンスは保持していたリソースを解放します。 

@PrePassivate 

コンテナは、ステートフル・セッションBeanを非アクティブ化する直前にこのメソッドを起動します。詳細は、次を参照してください。

 

@PostActivate 

コンテナは、以前に非アクティブ化したステートフル・セッションBeanを再びアクティブ化した直後にこのメソッドを起動します。 

表1-10に、javax.ejb.SessionBeanインタフェースでの指定に従って、ステートフル・セッションBeanが実装する必要のあるEJB 2.1ライフ・サイクル・メソッドをリストします。EJB 2.1ステートフル・セッションBeanでは、最低でも、すべてのコールバック・メソッド用に空の実装を用意する必要があります。

表1-10    EJB 2.1ステートフル・セッションBeanのライフ・サイクル・メソッド 
EJBメソッド  説明 

ejbCreate 

コンテナは、Beanの作成直前にこのメソッドを起動します。ステートレス・セッションBeanは、このメソッドでは何も行いません。ステートフル・セッションBeanは、このメソッドで状態を初期化可能です。 

ejbActivate 

コンテナは、Beanを再びアクティブ化した直後にこのメソッドを起動します。 

ejbPassivate 

コンテナは、Beanを非アクティブ化する直前にこのメソッドを起動します。詳細は、次を参照してください。

 

ejbRemove 

コンテナは、セッション・オブジェクトを破棄する前にこのメソッドを起動します。このメソッドにより、ファイル・ハンドルなどの外部リソースのクローズなど、必要なクリーンアップが実行されます。 

setSessionContext 

コンテナは、Beanを最初にインスタンス化した後にこのメソッドを起動します。このメソッドを使用して、Beanのコンテキストの参照を取得します。詳細は、「setSessionContextメソッドの実装」を参照してください。 

詳細は、次を参照してください。

ステートフル・セッションBeanの非アクティブ化が発生する状況

非アクティブ化を使用すると、コンテナは、Beanとその状態を2次記憶装置にシリアライズしてメモリーから削除することによって、非アクティブなアイドル状態のBeanインスタンスの対話状態を保持できます。非アクティブ化の前に、コンテナはPrePassivateまたはejbPassivateメソッドを起動し、データベース接続、TCP/IPソケットまたはオブジェクトのシリアライズによって透過的に非アクティブ化されないリソースなど、保持されたリソースをBean開発者がクリーンアップできるようにします。特定のオブジェクト・タイプのみシリアライズおよび非アクティブ化できます（「非アクティブ化できるオブジェクト・タイプ」を参照）。

非アクティブ化はデフォルトで有効化されています。非アクティブ化の有効化および無効化の詳細は、「非アクティブ化の構成」を参照してください。

OC4Jは、次の基準の任意の組合せが満たされる場合にステートフル・セッションBeanを非アクティブ化します。

Beanの非アクティブ化は、最低使用頻度アルゴリズムを使用して実行されます。つまり、非アクティブ化に対して適格なBeanのうち、OC4Jは使用頻度が最低のBeanを最初に非アクティブ化します。

また、OC4Jがこの基準をチェックする頻度および基準が満たされたときに非アクティブ化するインスタンス数を指定できます。

この基準の構成の詳細は、「非アクティブ化基準の構成」を参照してください。

非アクティブ化時のシリアライズに失敗した場合、コンテナはBeanをメモリーにリカバリして、処理前の状態にしようとします。非アクティブ化に失敗したBeanについては、その後非アクティブ化は試行されません。また、アクティブ化に失敗した場合、Beanとその参照はコンテナから完全に削除されます。

非アクティブ化されたBeanインスタンスのメソッドの1つをクライアントが起動すると、Beanを2次記憶装置からデシリアライズしてメモリーに戻すことによって、保持されていた対話状態のデータがアクティブ化されます。アクティブ化の前に、コンテナはejbActivateメソッドを起動し、ejbPassivate時に解放したリソースを開発者がリストアできるようにします。非アクティブ化の詳細は、EJBの仕様を参照してください。

ステートフル・セッションBeanでは、「非アクティブ化できるオブジェクト・タイプ」に示されている特定のタイプのオブジェクトのみが非アクティブ化されます。ユーザーがすべてのリソースを解放し、使用可能なタイプのオブジェクト内でのみ状態が存在するようにして、ステートフル・セッションBeanを非アクティブ化する準備をしていない場合、非アクティブ化は常に失敗します。

クラスタ内の非アクティブ化されたBeanに対して新規Beanデータが伝播されると、そのBeanインスタンスのデータは、伝播されたデータによって上書きされます。

非アクティブ化できるオブジェクト・タイプ

ステートフル・セッションBeanが非アクティブ化されると、そのBeanは2次記憶装置にシリアライズされます。シリアライズが成功するために、Beanの対話状態は、プリミティブ値と次のデータ型のみで構成されている必要があります。

PrePassivateメソッド（「EJB 3.0セッションBeanのライフ・サイクル・コールバック・インターセプタ・メソッドの構成」を参照）またはejbPassivateメソッド（「EJB 2.1セッションBeanのライフ・サイクル・コールバック・メソッドの構成」を参照）の完了後に、すべての非一時的フィールドがこれらの型であることを確認してください。このメソッド内では、すべての一時フィールドまたは非シリアライズ可能フィールドをNULLに設定する必要があります。

非アクティブ化されたステートフル・セッションBeanの格納場所

デフォルトでは、OC4Jは、ステートフル・セッションBeanを非アクティブ化したときに、シリアライズされたインスタンスを<OC4J_HOME>¥j2ee¥home¥persistenceに書き込みます。

非アクティブ化によってこのディレクトリ内の領域が使用され、非アクティブ化されたBeanが格納されます。非アクティブ化によって大量のディスク領域が割り当てられる場合は、使用可能な領域があるシステム上の別の場所にディレクトリを変更してください（「非アクティブ化の場所の構成」を参照）。

セッション・コンテキストとは

OC4Jは、各セッションBeanインスタンスのjavax.ejb.SessionContextを維持し、このセッション・コンテキストをBeanに対して使用可能にします。Beanは、セッション・コンテキスト内のメソッドを使用して、コンテナへのコールバック・リクエストを送信できます。また、EJBContextから継承されたメソッドを使用できます（「EJBコンテキストとは」を参照）。

詳細は、次を参照してください。

OC4Jは、最初にBeanをインスタンス化した後で、セッション・コンテキストを初期化します。Beanがセッション・コンテキストを取得できるようにするのは、Beanプロバイダの役割です。コンテナは、トランザクション・コンテキストからはこのメソッドをコールしません。この時点でBeanがセッション・コンテキストを保存しなかった場合、Beanは二度とセッション・コンテキストにアクセスできなくなります。

コンテナはこのメソッドをコールする際、SessionContextオブジェクトの参照をBeanに渡します。Beanは、この参照を後の使用のために格納できます。

オブジェクトが参照する対話状態をセッションBeanインスタンスが（setSessionContextメソッドまたはリソース・インジェクションを使用して）SessionContextに格納する場合、OC4Jはインスタンスの非アクティブ化の後も参照を保存およびリストアできます。OC4Jは、アクティブ化の際に、別の機能的に同等のSessionContextオブジェクトで元のSessionContextオブジェクトを置換できます。

注意

OC4Jでは、SessionContextのメソッドgetInvokedBusinessInterfaceがサポートされません。このメソッドをコールすると、OC4JによりUnsupportedOperationExceptionがスローされます。 

JPAエンティティとは

Java Enterprise Edition 5（Java EE 5）EJB 3.0仕様の一部であるJava永続性API（JPA）により、Javaの永続性は大幅に簡略化されています。このAPIを使用すると、オブジェクト・リレーショナル・マッピング・アプローチを通じて、Java EE 5アプリケーション・サーバーの内部とJava Standard Edition 5（Java SE 5）アプリケーションのEJBコンテナの外部で動作する標準的で移植可能な方法に基づいて、Javaオブジェクトをリレーショナル・データベース表にマッピングする方法を宣言的に定義できます。

JPAを使用すると、JPAエンティティとして任意のPOJOクラスを指定できます。このJavaオブジェクトには、（Java EE EJBコンテナの内部またはJava SEアプリケーションのEJBコンテナの外部にある）JPA永続性プロバイダから取得されるエンティティ・マネージャのサービスを通じてリレーショナル・データベースに永続化される非一時的フィールドが含まれます。

エンティティには、次の特徴があります。

エンティティは、コンテナ管理の永続性を使用してリレーショナル・データベースに自動的に格納される永続データを表します。各データはデータベースなどのデータ記憶域システムの形式で永続的に格納されるため、これらのエンティティは永続的です。サーバー障害、フェイルオーバー、ネットワーク障害が発生しても存続し続けます。エンティティが再びインスタンス化されると、以前のインスタンスの状態が自動的にリストアされます。

エンティティは、ビジネス・エンティティをモデル化するか、または単一のビジネス・プロセス内の複数のアクションをモデル化します。エンティティは、データを使用するビジネス・サービスの提供、およびそのデータの計算によく使用されます。たとえば、開発者が、発注されたアイテムを取得し計算するエンティティを実装する場合があります。エンティティで、タスクの実行中に複数の依存性のある永続オブジェクトを管理できます。

エンティティは、リモートにアクセス可能なコンポーネントではないため、ファイングレインな永続オブジェクトを表すことができます。

エンティティはオブジェクトを集約し、JPA永続性プロバイダのトランザクション、セキュリティおよび同時実行性サービスを使用してデータと関連オブジェクトを効率的に維持できます。

この項の内容は次のとおりです。

詳細は、第6章「JPAエンティティの実装」を参照してください。

JPAエンティティのコンテナ管理の永続性フィールドとは

コンテナ管理の永続性フィールドは、データベースに保存する必要のあるデータを表す状態フィールドです。

@Transientアノテーションを付けないかぎり、JPAエンティティのすべてのデータ・メンバーは永続性フィールドとみなされます。

エンティティの永続性ユニットで指定されるJPA永続性プロバイダ（「persistence.xmlファイルとは」を参照）により、永続性フィールドがデータベースに永続化されることが保証されます。

デフォルトでは、JPA永続性プロバイダにより、ほとんどのJavaプリミティブ型、プリミティブ型のラッパーおよび列挙の基本マッピングが自動的に構成されます。このマッピングは、@Basic、@Enumerated、@Temporalおよび@Lobアノテーションを使用してカスタマイズできます。

JPAエンティティのコンテナ管理の関連性フィールドとは

コンテナ管理の関連性（CMR）フィールドは、1つ以上の他のEJB 3.0エンティティまたはEJB 2.1コンテナ管理エンティティBeanとの永続関係を表す関連付けフィールドです。たとえば、受注管理アプリケーションでは、OrderEJBはLineItemEJB Beanのコレクションおよび単一のCustomerEJB Beanに関連している場合があります。

@Transientアノテーションを付けないかぎり、JPAエンティティのすべてのデータ・メンバーは永続性フィールドとみなされます。

エンティティの永続性ユニットで指定されるJPA永続性プロバイダ（「persistence.xmlファイルとは」を参照）により、永続性フィールドがデータベースに永続化されることが保証されます。

アノテーションまたはpersistence.xmlを使用してエンティティを構成し、他のエンティティに対するマッピングを指定する必要があります。この構成により、エンティティ間の相互関係と、JPA永続性プロバイダでリレーショナル・データベースに参照をマッピングする方法を指定します。

たとえば、関連マッピング・アノテーションの@OneToOne、@ManyToOne、@OneToManyおよび@ManyToManyを使用して、任意の永続関係の関連マッピングを構成できます。

エンティティ関連（E-R）には、次の特徴があります。

詳細は、次を参照してください。

JPAエンティティのライフ・サイクル

図1-5に、JPAエンティティのライフ・サイクルを示します。

図1-5    JPAエンティティのライフ・サイクル


画像の説明

表1-11に、アノテーションを使用して定義できるJPAエンティティのオプションのライフ・サイクル・コールバック・メソッドをリストします。EJB 3.0エンティティでは、これらのメソッドを実装する必要はありません。

表1-11    JPAエンティティのライフ・サイクル・メソッド 
アノテーション  説明 

@PrePersist 

このオプションのメソッドは、対応するEntityManager永続化操作が実行される前にエンティティに対して起動されます。このコールバックは、これらの操作がカスケードされるすべてのエンティティに対して起動されます。このコールバックがExceptionをスローした場合は、現在のトランザクションがロールバックされます。 

@PostPersist 

このオプションのメソッドは、対応するEntityManager永続化操作が実行された後にエンティティに対して起動されます。このコールバックは、これらの操作がカスケードされるすべてのエンティティに対して起動されます。このメソッドは、データベース挿入操作の後に起動されます。これは、永続化操作の直後、フラッシュ操作の直後またはトランザクションの終了時の場合があります。このコールバックがExceptionをスローした場合は、現在のトランザクションがロールバックされます。 

@PreRemove 

このオプションのメソッドは、対応するEntityManager削除操作が実行される前にエンティティに対して起動されます。このコールバックは、これらの操作がカスケードされるすべてのエンティティに対して起動されます。このコールバックがExceptionをスローした場合は、現在のトランザクションがロールバックされます。 

@PostRemove 

このオプションのメソッドは、対応するEntityManager削除操作が実行された後にエンティティに対して起動されます。このコールバックは、これらの操作がカスケードされるすべてのエンティティに対して起動されます。このメソッドは、データベース削除操作の後に起動されます。これは、削除操作の直後、フラッシュ操作の直後またはトランザクションの終了時の場合があります。このコールバックがExceptionをスローした場合は、現在のトランザクションがロールバックされます。 

@PreUpdate 

このオプションのメソッドは、エンティティ・データに対するデータベース更新操作の前に起動されます。これは、エンティティ状態更新時、フラッシュ操作時またはトランザクションの終了時の場合があります。

OC4Jは、実際の更新が必要な場合のみ（データベースへのSQLの送信が準備されている場合のみ）このメソッドをコールします。この点を、実際の変更が必要かどうかにかかわらずコールされるpost-updateコールバックと比較してください。 

@PostUpdate 

このオプションのメソッドは、エンティティ・データに対するデータベース更新操作の後に起動されます。これは、エンティティ状態更新時、フラッシュ操作時またはトランザクションの終了時の場合があります。

OC4Jは、実際の更新が不要な場合（データベースにSQLを送信する必要がないと判断された場合）でも、このメソッドをコールします。オブジェクトが実際に変更された場合にのみ通知するには、pre-updateコールバックを使用します。 

@PostLoad 

このオプションのメソッドは、エンティティがデータベースから現在の永続性コンテキストにロードされた後またはリフレッシュ操作が適用された後、かつ問合せ結果が返されるか、アクセスされるか、または関連付けが横断される前に起動されます。 

詳細は、次を参照してください。

JPAエンティティの主キー

各JPAエンティティには、他のインスタンスから一意に識別するための主キーが存在する必要があります。主キー（または主キーとなる複合キー内のフィールド）は、永続フィールドである必要があります。

主キー内のすべてのフィールドは次の型に制限されます。

このリリースでは、単一の一般的なシリアライズ可能Javaプリミティブまたはオブジェクト型から構成される主キーを定義できます。Beanクラス内で宣言される主キー変数は、publicとして宣言する必要があります（「JPAエンティティの単純な主キー・フィールドの構成」を参照）。

主キー値を自分で割り当てるか、より一般的には自動生成された主キーを作成できます（「JPAエンティティの自動主キー生成の構成」を参照）。

注意

エンティティBeanの主キーが設定されると、EJB 3.0仕様では、その変更が禁止されています。したがって、エンティティ・コンポーネント・インタフェースに主キー設定メソッドを公開しないでください。 

詳細は、「JPAエンティティの主キーの構成」を参照してください。

JPAエンティティの問合せ方法

EJB 3.0では、javax.persistence.EntityManagerを使用してEJB 3.0エンティティを作成、検索、マージおよび維持します。エンティティを検索するには、EntityManager問合せAPIを使用します（「JPA EntityManager問合せAPIについて」を参照）。

適切な問合せ構文を使用して、選択基準を表現できます（「JPAエンティティの問合せ構文について」を参照）。

問合せヒントを使用すると、EJB 3.0 JPA永続性プロバイダでこのAPIのベンダー拡張を使用できます（「JPA問合せでのTopLink問合せヒントの構成」を参照）。

JPA EntityManager問合せAPIについて

EJB 3.0では、javax.persistence.EntityManagerおよびjavax.persistence.Query APIを使用して名前付き問合せまたは動的問合せを作成および実行できます。

Query APIを使用して、パラメータのバインド、ヒントの構成および返される結果数の制御を行うことができます。

詳細は、次を参照してください。

JPAの名前付き（事前定義）問合せ

名前付き問合せは、EJB 2.1 finderメソッドをEJB 3.0で改良したものです。EJB 3.0では、メタデータを使用して名前付き問合せを実装でき（「JPA名前付き問合せの実装」を参照）、実行時に名前を指定して問合せを作成および実行できます（「EntityManagerでの名前付き問合せの作成」を参照）。

OC4Jでは、Java永続性問合せ言語とネイティブSQLの名前付き問合せの両方がサポートされます。

JPA動的（非定型）問合せ

動的問合せは、実行時に作成、構成および実行できる問合せです。名前付き問合せに加えて動的問合せを使用できます。

OC4Jでは、Java永続性問合せ言語とネイティブSQLの名前付き問合せの両方がサポートされます。

TopLink問合せおよび式フレームワークを使用して動的問合せを作成することもできます（「EntityManagerを使用した動的TopLink式問合せの作成」を参照）。

JPAエンティティの問合せ構文について

表1-12に、JPAエンティティの問合せの定義に使用できる問合せ構文のタイプをまとめます。

表1-12    OC4JによるJPAエンティティの問合せ構文のサポート 
問合せ構文  参照先 

Java永続性問合せ言語 

「Java永続性問合せ言語の問合せ構文について」 

ネイティブSQL 

「EJB 2.1のネイティブSQL問合せ構文について」 

移植と最適化が可能なため、Java永続性問合せ言語の使用をお薦めします。

Java永続性問合せ言語の問合せ構文について

Java永続性問合せ言語は、移植と最適化が可能な形式で問合せセマンティクスを定義するために使用できる指定言語です。

SQLと似ていますが、Java永続性問合せ言語はネイティブSQLよりもはるかに優れています。SQLでは列名を使用して表に対して問合せを行いますが、Java永続性問合せ言語では、Beanの抽象スキーマ名およびフィールドを問合せ内で使用し、EJB 3.0エンティティに対して問合せを行います。Java永続性問合せ言語の文では、オブジェクト用語を使用します。JPA永続性プロバイダは、アプリケーションのデプロイ時に、Java永続性問合せ言語の文を適切なデータベースSQL文に変換します。したがって、JPA永続性プロバイダは、エンティティ名とその永続フィールド名を、適切なデータベース表名と列名に変換します。Java永続性問合せ言語は、OC4Jでサポートされているすべてのデータベースに移植可能です。

EJB 3.0では、Java永続性問合せ言語構文にはEJB 2.1 EJB QL（「EJB 2.1問合せ構文について」を参照）のすべての機能に加えて、バルク更新と削除、JOIN操作、GROUP BY、HAVING、投影、副問合せ、EJB 3.0のEntityManager APIを使用した動的問合せ（「JPA動的（非定型）問合せ」を参照）でのJava永続性問合せ言語の使用などの追加機能があります。

詳細は、JSR-220 Enterprise JavaBeansバージョン3.0のJava永続性API仕様の第4章を参照してください。

OC4Jでは、Java永続性問合せ言語を次の重要な機能とともにサポートしています。

EJB 3.0を使用した場合、OC4Jでは、SQRTや日付、時刻、タイムスタンプの各オプションなど、EJB 3.0永続性仕様で定義されているすべての拡張Java永続性問合せ言語機能がサポートされます。

EJB 3.0のネイティブSQL問合せ構文について

このリリースでは、TopLink JPA永続性プロバイダは、指定された問合せ構文を受け取り（「JPAエンティティの問合せ構文について」を参照）、基礎となるリレーショナル・データベースに固有のStructured Query Language（SQL）を生成します。

Java永続性問合せ言語は、移植と最適化が可能なため、推奨される構文です。

ネイティブSQLは、Java永続性問合せ言語でサポートされない基礎となるリレーショナル・データベースの高度な問合せ機能を利用する場合に適しています。

OC4Jでは、名前付き問合せと動的問合せの両方でネイティブSQLがサポートされます。

EJB 2.1エンティティBeanとは

エンティティBeanはEJB 2.1 Enterprise Beanコンポーネントであり、永続データの管理および複雑なビジネス・ロジックの実行を行います。複数の依存性のあるJavaオブジェクトを使用可能で、主キーによって一意に識別可能です。

エンティティBeanは、次のいずれかの方法により、ビジネス・データを永続的にします。

コンテナ管理の永続性アーキテクチャとBean管理の永続性アーキテクチャを選択する方法の詳細は、「Bean管理の永続性を使用する場合とコンテナ管理の永続性を使用する場合」を参照してください。

エンティティBeanのデータはデータベースなどのデータ記憶域の形式で永続的に格納されるため、エンティティBeanは永続的です。サーバー障害、フェイルオーバー、ネットワーク障害が発生しても存続し続けます。エンティティBeanが再びインスタンス化されると、以前のインスタンスの状態が自動的にリストアされます。OC4Jは、エンティティBeanをメモリーから削除する必要がある場合にこの状態を管理します（「エンティティBeanの非アクティブ化が発生する状況」を参照）。

エンティティBeanは、ビジネス・エンティティをモデル化するか、または単一のビジネス・プロセス内の複数のアクションをモデル化します。エンティティBeanは、データを使用するビジネス・サービスの提供、およびそのデータの計算によく使用されます。たとえば、開発者が、発注されたアイテムを取得し計算するエンティティBeanを実装する場合があります。エンティティBeanで、タスクの実行中に複数の依存性のある永続オブジェクトを管理できます。

一般的な設計パターンでは、エンティティBeanをクライアント・インタフェースとして機能するセッションBeanと対にします。エンティティBeanは、機能をカプセル化し、永続データおよび依存オブジェクト（通常はファイングレイン）との関連を表すコースグレインなオブジェクトとして機能します。したがって、クライアントをデータから分離できるため、データが変更されてもクライアントは影響を受けません。効率を上げるため、セッションBeanをエンティティBeanと同一JVM上に置き、ローカル・インタフェースを通じて複数のエンティティBean間を調整できます。これは、セッション・ファサード・デザインと呼ばれます。セッション・ファサード・デザインの詳細は、Webサイトhttp://java.sun.comを参照してください。

エンティティBeanはオブジェクトを集約し、コンテナのトランザクション、セキュリティおよび同時実行性サービスを使用してデータと関連オブジェクトを効率的に維持できます。

この項の内容は次のとおりです。

詳細は、第13章「EJB 2.1エンティティBeanの実装」を参照してください。

コンテナ管理の永続性を備えたEJB 2.1エンティティBeanとは

エンティティBeanの永続データをコンテナで管理することを選択した場合は、コンテナ管理の永続性を備えたエンティティBeanを定義します。コンテナ管理の永続性を備えたエンティティBeanのクラスは、抽象クラス（コンテナが、実行時に使用される実装クラスを提供する）であり、その永続データは、単純なデータに対してはコンテナ管理の永続性フィールド（「コンテナ管理の永続性フィールドとは」を参照）として指定され、コンテナ管理の永続性を備えた他のエンティティBeanとの関連に対してはコンテナ管理の関連性フィールド（「コンテナ管理の関連性フィールドとは」を参照）として指定されます。この場合、コンテナにより、永続データのデータベースへの格納およびリロードが行われるため、Beanのデータの永続性を管理するための一部のコールバック・メソッドを実装する必要がありません（「コンテナ管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクル」を参照）。コンテナ管理の永続性を使用する場合、コンテナが永続的マネージャ・クラスを起動し、これによって永続的管理ビジネス・ロジックが提供されます。OC4Jでは、TopLink永続性マネージャがデフォルトで使用されます。さらに、主キー（「コンテナ管理の永続性を備えたエンティティBeanの主キー」を参照）用の管理を提供する必要がありません。コンテナによってBeanのキーが提供されます。

詳細は、次を参照してください。

コンテナ管理の永続性フィールドとは

コンテナ管理の永続性フィールドは、データベースに保存する必要のあるデータを表す状態フィールドです。

コンテナ管理の永続性フィールドを指定することで、OC4Jに対して、フィールドの値を必ずデータベースに保存するよう指示します。コンテナ管理の永続性を備えたエンティティBeanの他のすべてのフィールドは、非永続（一時的）とみなされます。

EJB 2.1を使用した場合は、コンテナ管理の永続性フィールドを明示的に指定する必要があります（「コンテナ管理の永続性を備えたEJB 2.1エンティティBeanにおけるコンテナ管理の永続性フィールドの構成」を参照）。

コンテナ管理の関連性フィールドとは

コンテナ管理の関連性フィールドは、コンテナ管理の永続性を備えた他の1つ以上のエンティティBeanとの永続関係を表す関連付けフィールドです。たとえば、受注管理アプリケーションでは、OrderEJBはLineItemEJB Beanのコレクションおよび単一のCustomerEJB Beanに関連している場合があります。

コンテナ管理の関連性フィールドを指定することで、OC4Jに対して、コンテナ管理の永続性を備えた1つ以上の関連エンティティBeanへの参照を必ずデータベースに保存するよう指示します。このため、コンテナ管理の永続性を備えたエンティティBean間の関連性は、コンテナ管理の関連性（またはコンテナ管理の永続性を備えたあるエンティティBeanから別のエンティティBeanへのマッピング）と呼ばれることがあります。

コンテナ管理の関連性には次の特性があります。

詳細は、次を参照してください。

コンテナ管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクル

図1-6に、コンテナ管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクルを示します。

図1-6    コンテナ管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクル


画像の説明

表1-13に、javax.ejb.EntityBeanインタフェースでの指定に従って、コンテナ管理の永続性を備えたエンティティBeanが実装する必要のあるEJB 2.1 Enterprise Beanのライフ・サイクル・メソッドをリストします。コンテナ管理の永続性を備えたEJB 2.1エンティティBeanでは、最低でも、すべてのコールバック・メソッド用に空の実装を用意する必要があります。

表1-13    コンテナ管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクル・メソッド 
EJBメソッド  説明 

ejbCreate 

ホーム・インタフェースで宣言された各createメソッドに対し、対応するejbCreateメソッドを実装する必要があります。クライアントがcreateメソッドを起動すると、コンテナはまずコンストラクタを起動してオブジェクトをインスタンス化し、次に対応するejbCreateメソッドを起動します。

コンテナ管理の永続性を備えたエンティティBeanの場合は、このメソッドを使用してコンテナ管理の永続性フィールドを初期化します。

すべてのejbCreateメソッドの戻り型は、Beanの主キーの型です。

オプションで、一意の主キーでBeanを初期化して返すこともできます。コンテナに依存して主キーを作成および初期化する場合は、nullを返します。 

ejbPostCreate 

コンテナは、環境の設定後、このメソッドを起動します。各ejbCreateメソッドに対し、同じ引数を持つejbPostCreateメソッドが存在する必要があります。

コンテナ管理の永続性を備えたエンティティBeanの場合は、この実装を空のままにするか、実装を使用してエンティティ・コンテキストからパラメータを初期化できます。 

ejbRemove 

コンテナは、エンティティBeanを破棄する前にこのメソッドを起動します。

コンテナ管理の永続性を備えたエンティティBeanの場合は、この実装を空のままにするか、実装を使用して必要なクリーンアップ（たとえば、ファイル・ハンドルなどの外部リソースのクローズなど）を実行できます。 

ejbStore 

コンテナは、トランザクションのコミットの直前にこのメソッドを起動します。これにより、永続データを、データベースなどの外部リソースに格納します。

コンテナ管理の永続性を備えたエンティティBeanでは、この実装を空のままにできます。 

ejbLoad 

コンテナは、データをデータベースから再初期化する必要がある場合にこのメソッドを起動します。通常、これはエンティティBeanのアクティブ化の後に行われます。

コンテナ管理の永続性を備えたエンティティBeanでは、この実装を空のままにできます。 

ejbActivate 

コンテナは、以前に非アクティブ化されたオブジェクトをアクティブ化する前にこのメソッドを直接コールします。リソースの再取得が必要な場合、このメソッドで実行します。 

ejbPassivate  

コンテナは、オブジェクトを非アクティブ化する前にこのメソッドをコールします。ejbActivateで容易に再作成できるリソースを解放することにより、記憶領域を節約します。通常は、ソケットまたはデータベース接続などのように、非アクティブ化できないリソースを解放します。これらのリソースは、ejbActivateメソッドで取得します。 

詳細は、次を参照してください。

コンテナ管理の永続性を備えたエンティティBeanの主キー

各エンティティBeanには、他のインスタンスから一意に識別するための主キーが存在します。主キー（または主キーとなる複合キー内のフィールド）を、デプロイメント・ディスクリプタのコンテナ管理による永続的フィールドとして宣言する必要があります。

主キー内のすべてのフィールドは次の型に制限されます。

主キーは、次のいずれかの方法で定義できます。

通常は、OC4Jによって自動的に主キー値が割り当てられます。OC4Jによる主キー値の割当て方法を構成するには、TopLink永続性APIを使用します。詳細は、次を参照してください。

詳細は、「コンテナ管理の永続性を備えたEJB 2.1エンティティBeanの主キーの構成」を参照してください。

Bean管理の永続性を備えたEJB 2.1エンティティBeanとは

エンティティBeanの永続データを自分で管理することを選択した場合は、Bean管理の永続性を備えたエンティティBeanを定義します。Bean管理の永続性を備えたエンティティBeanのクラスは、具象クラス（実行時に使用される実装をユーザーが提供）であり、その永続データは、単純なデータに対してはBean管理の永続性フィールド（「Bean管理の永続性フィールドとは」を参照）として指定され、Bean管理の永続性を備えた他のエンティティBeanとの関連に対してはBean管理の関連性フィールド（「Bean管理の関連性フィールドとは」を参照）として指定されます。この場合、すべてのコールバック・メソッドを実装して、永続データのデータベースへの格納およびリロードなど、Beanのデータの永続性を管理する必要があります（「Bean管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクル」を参照）。Bean管理の永続性を使用する場合は、永続性管理ビジネス・ロジックを実現するコードを提供する必要があります。また、主キーの管理を提供する必要があります（「Bean管理の永続性を備えたエンティティBeanの主キー」を参照）。

Bean管理の永続性を備えたエンティティBeanを読取り専用として指定し（「Bean管理の永続性を備えた読取り専用エンティティBeanの構成」を参照）、選択するコミット・オプションに応じてOC4JがBean管理の永続性を備えた読取り専用エンティティBeanを提供する最適化を利用できます（「エンティティBeanのコミット・オプション」を参照）。

詳細は、次を参照してください。

Bean管理の永続性フィールドとは

Bean管理の永続性を使用する場合は、記述するコードによって、Bean管理の永続性を備えたエンティティBeanで維持されるフィールドが決まります。

Bean管理の関連性フィールドとは

Bean管理の永続性を使用する場合は、記述するコードによって、Bean管理の永続性を備えたエンティティBean間の関連が実装されます。

Bean管理の永続性を備えたEJB 2.1エンティティBeanのライフ・サイクル

表1-14に、javax.ejb.EntityBeanインタフェースでの指定に従って、Bean管理の永続性を備えたエンティティBeanが実装する必要のあるライフ・サイクル・メソッドをリストします。

Bean管理の永続性を備えたエンティティBeanの場合は、すべてのライフ・サイクル・メソッドの完全な実装を提供する必要があります。

表1-14    Bean管理の永続性を備えたエンティティBeanのEJBライフ・サイクル・メソッド 
EJBメソッド  説明 

ejbCreate 

ホーム・インタフェースで宣言された各createメソッドに対し、対応するejbCreateメソッドを実装する必要があります。クライアントがcreateメソッドを起動すると、コンテナはまずコンストラクタを起動してオブジェクトをインスタンス化し、次に対応するejbCreateメソッドを起動します。ejbCreateメソッドにより、次の処理が実行されます。

  • データ用に、データベース行などの永続記憶域を作成します。

  • 一意の主キーを初期化して返します。

 

ejbPostCreate 

コンテナは、環境の設定後、このメソッドを起動します。各ejbCreateメソッドに対し、同じ引数を持つejbPostCreateメソッドが存在する必要があります。このメソッドを使用して、パラメータの初期化をエンティティ・コンテキスト内で、またはそこから実行することが可能です。 

ejbRemove 

コンテナは、セッション・オブジェクトを破棄する前にこのメソッドを起動します。このメソッドにより、ファイル・ハンドルなどの外部リソースのクローズなど、必要なクリーンアップが実行されます。 

ejbStore 

コンテナは、トランザクションのコミットの直前にこのメソッドを起動します。これにより、永続データを、データベースなどの外部リソースに格納します。  

ejbLoad 

コンテナは、データをデータベースから再初期化する必要がある場合にこのメソッドを起動します。通常、これはエンティティBeanのアクティブ化の後に行われます。  

ejbActivate 

コンテナは、以前に非アクティブ化されたオブジェクトをアクティブ化する前にこのメソッドを直接コールします。リソースの再取得が必要な場合、このメソッドで実行します。 

ejbPassivate  

コンテナは、オブジェクトを非アクティブ化する前にこのメソッドをコールします。ejbActivateで容易に再作成できるリソースを解放することにより、記憶領域を節約します。通常は、ソケットまたはデータベース接続などのように、非アクティブ化できないリソースを解放します。これらのリソースは、ejbActivateメソッドで取得します。 

詳細は、次を参照してください。

Bean管理の永続性を備えたエンティティBeanの主キー

エンティティBeanの主キーは、特定のタイプのエンティティBeanクラスのインスタンスを別のインスタンスと区別する、一意に識別可能な値です。各エンティティBeanには、永続的な識別情報が関連付けられています。つまり、主キーを保有している場合に取得可能な一意の識別情報が含まれています。主キーがあれば、クライアントはエンティティBeanを取得可能です。Beanが使用不可の場合、コンテナはBeanをインスタンス化し、永続データを再移入します。

一意のキーのタイプは、Beanプロバイダによって定義されています。

主キー内のすべてのフィールドは次の型に制限されます。

主キーは、次のいずれかの方法で定義できます（どちらの場合も、Bean管理の永続性を備えたエンティティBeanの場合は、ejbCreateメソッドで主キーを作成します）。

エンティティ・コンテキストとは

OC4Jは、コンテナ管理の永続性を備えた各EJB 2.1エンティティBeanまたはBean管理の永続性を備えたエンティティBeanインスタンスのjavax.ejb.EntityContextを維持し、このエンティティ・コンテキストをBeanに対して使用可能にします。Beanは、エンティティ・コンテキスト内のメソッドを使用して、コンテナへのコールバック・リクエストを送信できます。また、EJBContextから継承されたメソッドを使用できます（「EJBコンテキストとは」を参照）。

詳細は、次を参照してください。

エンティティBeanの非アクティブ化が発生する状況

エンティティBeanの非アクティブ化は、コンテナ管理の永続性を備えたEJB 2.1エンティティBeanにのみ適用されます。

OC4Jは、コンテナがエンティティ・オブジェクト識別情報からインスタンスの関連付けを解除すること、また使用可能なインスタンスのプールにインスタンスを戻すことを決定したときに、インスタンスを非アクティブ化します。OC4Jは、インスタンスのejbPassivateメソッドをコールして、インスタンスがプールにある間は保持できないリソース（通常はejbActivateメソッドに割り当てられている）を解放する機会をインスタンスに与えます。このメソッドは、未指定のトランザクション・コンテキストで実行されます。エンティティBeanは、このメソッド中にアクセッサ・メソッドを使用して永続状態または関連へのアクセスを試行することはできません。

エンティティBeanのコミット・オプション

コミット・オプションにより、トランザクション・コミット時にエンティティBeanインスタンスの状態が決定され、OC4Jが特定のアプリケーション条件を最適化できる柔軟性が提供されます。

表1-15に、EJB 2.1仕様によって定義されているコミット・オプションをリストし、OC4Jでサポートされるオプションを示します。

表1-15    OC4JによるエンティティBeanのコミット・オプションのサポート 
コミット・オプション  OC4Jサポート  説明  インスタンス状態がデータベースに書き込まれるか  インスタンスは準備完了  インスタンス状態は有効なまま  利点  短所 

A 
1  

キャッシュされたBean: トランザクションの最後に、インスタンスは準備完了状態（キャッシュ済）になり、インスタンス状態は有効です（アクティブ化の後にejbLoadが1回コールされる）。 
 
 
 

データベース・アクセスが最も少なくなります。 

排他的アクセスが必要です。

複数スレッドが同じBeanインスタンスを共有します（パフォーマンスが悪くなる）。 

B 
 

失効Bean: トランザクションの最後に、インスタンスは準備完了状態（キャッシュ済）になりますが、インスタンス状態は無効です。トランザクションごとにejbLoadおよびejbStoreがコールされます。 
 
 
 

データベース・アクセスが中程度です。

同時リクエストが可能です。 

同じデータを表す複数のBeanインスタンスのオーバーヘッドが生じます。

各トランザクションがejbLoadをコールします。 

C 
2  

プールされたBean: トランザクションの最後に、インスタンスもその状態も無効になります（インスタンスは非アクティブ化され、プールに返される）。すべてのクライアント・コールで、ejbActivate、ejbLoad、ビジネス・メソッド、ejbStoreおよびejbPassivateがこの順序で実行されます。 
 
 
 

スケーラビリティが最大です。

同時リクエストが可能です。

接続を保持する必要がありません。 

データベース・アクセスが最も多くなります（ビジネス・メソッド・コールのたび）。

キャッシングが行われません。 
1 Bean管理の永続性を備えたエンティティBeanのみ（「コミット・オプションおよびBMPアプリケーション」を参照）。

2 コンテナ管理の永続性を備えたエンティティBeanのみ（「コミット・オプションおよびCMPアプリケーション」を参照）。

コミット・オプションおよびCMPアプリケーション

TopLink永続性マネージャを使用してOC4JにデプロイされたEJB 2.1 CMPアプリケーションでは、デフォルトで、OC4Jはコミット・オプションCに近いTopLink構成を使用します。このオプションにより、最も広範なアプリケーションに対してパフォーマンスとスケーラビリティが最大になります。

OC4J EJB 2.1 CMPは、ライフ・サイクル・メソッド・コールに関してオプションCに準拠します。ただし、TopLink永続マネージャには次の新機能が導入されています。

TopLinkペシミスティックまたはオプティミスティック・ロック・ポリシーとともにロックまたは同期を使用して、同じBeanへの同時サービスを処理できます。これにより、インスタンスが失効データで更新されないことを保証したまま、同じインスタンスの同時アクセスのパフォーマンスを最大にすることができます。

ファイングレインなTopLink構成変更の詳細は、次を参照してください。

コミット・オプションおよびBMPアプリケーション

OC4JにデプロイされたEJB 2.1 BMPアプリケーションの場合は、コミット・オプションAまたはCを構成できます（「Bean管理の永続性を備えたエンティティBeanのコミット・オプションの構成」を参照）。

Bean管理の永続性を備えたエンティティBeanを読取り専用として構成した場合、OC4Jはコミット・オプションAの特殊ケースを使用してパフォーマンスを向上させます。この場合、OC4Jはインスタンスをキャッシュし、トランザクションのコミット時にインスタンスの更新やejbStoreのコールは行いません。詳細は、「Bean管理の永続性を備えた読取り専用エンティティBeanの構成」を参照してください。

BMPコミット・オプションAおよびBean管理の永続性を備えた読取り専用エンティティBeanは個別に使用できます（つまり、読取り専用を使用せずにコミット・オプションAでBean管理の永続性を備えたエンティティBeanを構成でき、またコミット・オプションAでBean管理の永続性を備えたエンティティBeanを構成せずに読取り専用を使用できる）。

EJB 2.1エンティティBeanの問合せ方法

EJB 2.1エンティティBeanインスタンスを問い合せるには、finderまたはselectメソッドを使用します（「finderメソッドについて」および「selectメソッドについて」を参照）。

どちらの場合も、適切な問合せ構文を使用して、選択基準を表現します（「EJB 2.1問合せ構文について」を参照）。

詳細は、第16章「EJB 2.1問合せの実装」を参照してください。

EJB 2.1問合せ構文について

表1-16に、EJB問合せの定義に使用できる問合せ構文のタイプをまとめます。

表1-16    OC4J EJB 2.1問合せ構文のサポート 
問合せ構文  参照先 

EJB QL 

「EJB 2.1問合せ構文について」 

TopLink 

「TopLink問合せ構文について」 

    事前定義のfinder 

「事前定義のTopLink finder」 

    デフォルトのfinder 

「デフォルトのTopLink finder」 

    カスタムfinder 

「カスタムTopLink finder」 

    カスタムselect 

「カスタムTopLink selectメソッド」 

ネイティブSQL 

「EJB 2.1のネイティブSQL問合せ構文について」 

移植と最適化が可能なため、EJB QLの使用をお薦めします。

EJB QL問合せ構文について

EJB QLは、移植と最適化が可能な形式でfinderおよびselectメソッド（「finderメソッドについて」および「selectメソッドについて」を参照）のセマンティクスを定義するために使用される指定言語です。EJB QL文は、各finderおよびselectメソッドに関連付けられています。

SQLと似ていますが、EJB QLはネイティブSQLよりもはるかに優れています。SQLでは列名を使用して表に対して問合せを行いますが、EJB QLでは、Beanの抽象スキーマ名およびコンテナ管理の永続性フィールドと関連性フィールドを問合せ内で使用し、コンテナ管理の永続性を備えたエンティティBeanに対して問合せを行います。EJB QL文では、オブジェクト用語を使用します。コンテナは、アプリケーションのデプロイ時に、EJB QL文を適切なデータベースSQL文に変換します。したがって、コンテナは、エンティティBean名、コンテナ管理の永続性フィールド名およびコンテナ管理の関連性フィールド名を、適切なデータベース表名と列名に変換します。EJB QLは、OC4Jでサポートされているすべてのデータベースに移植可能です。

EJB 2.1では、EJB QLはSQL92のサブセットであり、エンティティBeanの抽象スキーマに定義されている関連へのナビゲーションを可能にする拡張機能があります。抽象スキーマは、エンティティBeanのデプロイメント・ディスクリプタの一部で、Beanの永続フィールドと関連を定義します。「抽象」という用語によって、このスキーマは基礎となるデータ・ストアの物理的なスキーマと区別されます。EJB QL問合せの有効範囲には、同じEJB JARファイルにパッケージされている関連のエンティティBeanの抽象スキーマが含まれるため、抽象スキーマ名はEJB QL問合せで参照されます。

コンテナ管理の永続性を使用するエンティティBeanの場合、EJB QL問合せはすべてのfinderメソッド（findByPrimaryKeyを除く）について定義する必要があります。OC4JをTopLink永続性マネージャとともに使用すると、事前定義およびデフォルトのfinderおよびselectメソッドを利用できます（「TopLink finder」および「カスタムTopLink selectメソッド」を参照）。EJB QL問合せによって、finderまたはselectメソッドの起動時にEJBコンテナで実行される問合せが決まります。

Oracle Application Serverでは、EJB QLを次の重要な機能とともにサポートしています。

EJB 2.1を使用した場合、OC4Jは、EJB 2.1で使用できないSQRTと日付、時刻、タイムスタンプの各オプションをサポートするために独自のEJB QL拡張を提供します（「OC4J EJB 2.1 EJB QL拡張」を参照）。

TopLink問合せ構文について

このリリースでは、TopLinkはデフォルトの永続性マネージャ（「TopLink EJB 2.1永続性マネージャ」を参照）であるため、TopLink問合せおよび式フレームワークを使用してEJB 2.1のfinderまたはselectメソッドの選択基準を表現できます。このEJB QLのかわりとなる手段には多数の利点があります（「TopLink問合せおよび式の利点」を参照）。

TopLink Workbenchを使用して、ejb-jar.xmlファイルをカスタマイズし、TopLink問合せおよび式フレームワークを使用して高度なfinderおよびselectメソッドを作成できます。

TopLink永続性マネージャが提供する事前定義およびデフォルトのfinderおよびselectメソッドを利用することもできます（「TopLink finder」および「カスタムTopLink selectメソッド」を参照）。

詳細は、次を参照してください。

TopLink問合せおよび式の利点

TopLink式フレームワークを使用すると、ドメイン・オブジェクト・モデルに基づいて問合せ検索基準を指定できます。

式には、SQLと比べてデータベースへのアクセス時に次の利点があります。

EJB 2.1のネイティブSQL問合せ構文について

このリリースでは、TopLink永続性マネージャは、指定された問合せ構文を受け取り（「EJB QL問合せ構文について」または「TopLink問合せ構文について」を参照）、基礎となるリレーショナル・データベースに固有のStructured Query Language（SQL）を生成します。

EJB QLは、移植と最適化が可能なため、推奨される構文です。

ネイティブSQLは、EJB QLでサポートされない基礎となるリレーショナル・データベースの高度な問合せ機能を利用する場合に適しています。

EJB 2.1およびTopLink問合せ構文を使用した場合、次のものを使用できます。

ネイティブSQLを使用するには、直接JDBCコールを使用する必要があります。

finderメソッドについて

finderメソッドは、名前がfindで始まるEJBメソッドであり、EJBのHomeインタフェースで定義し（「EJB 2.1ホーム・インタフェースの実装」を参照）、問合せに関連付けてそのEJBタイプの1つ以上のインスタンスを返します。デプロイ時に、OC4Jは、関連付けられている問合せを実行するこのメソッドの実装を提供します。

finderメソッドは、クライアントがコンテナ管理の永続性を備えたEJB 2.1エンティティBeanを取得する手段です。EJB 2.1を使用して、次の処理を実行できます。

単一のEJBインスタンスを返すfinderの戻り型は、そのEJBインスタンスの型です。

複数のEJBインスタンスを返すfinderの戻り型は、Collectionです。一致する項目が見つからない場合は、空のCollectionが返されます。重複した項目を返さないようにするには、関連付けられているEJB問合せでDISTINCTキーワードを指定します。

すべてのfinderは、FinderExceptionをスローします。

最低でも、findByPrimaryKey finderメソッドを公開して、主キーを使用して各エンティティのBeanの参照を取得する必要があります。

TopLink finder

TopLink永続性マネージャは、OC4JエンティティBeanに対して様々な事前定義（「事前定義のTopLink finder」を参照）およびデフォルト（「デフォルトのTopLink finder」を参照）のfinderを提供します。これらのfinderは、他のfinderと同様にクライアントに公開できます。対応する問合せを指定する必要はありません。カスタムTopLink finderも作成できます（「カスタムTopLink finder」を参照）。

事前定義のTopLink finder

表1-17に、コンテナ管理の永続性を備えたEJB 2.1エンティティBeanに対して公開できる事前定義のfinderをリストします。TopLink永続性マネージャは、表1-17にリストされているメソッド名を予約しています。

表1-17    事前定義のTopLink CMP finder 
メソッド  引数  戻り型 

findAll 

() 

Collection 

findManyByEJBQL 

(String ejbql)
(String ejbql, Vector args) 

Collection 

findManyByQuery 

(DatabaseQuery query)
(DatabaseQuery query, Vector args) 

Collection 

findManyBySQL 

(String sql)
(String sql, Vector args) 

Collection 

findByPrimaryKey 

(Object primaryKeyObject) 

EJBObjectまたはEJBLocalObject1 

findOneByEJBQL 

(String ejbql) 

コンポーネント・インタフェース 

findOneByEJBQL 

(String ejbql, Vector args) 

EJBObjectまたはEJBLocalObject1 

findOneByQuery 

(DatabaseQuery query) 

コンポーネント・インタフェース 

findOneByQuery 

(DatabaseQuery query, Vector args) 

EJBObjectまたはEJBLocalObject1 

findOneBySQL 

(String sql) 

コンポーネント・インタフェース 

findOneBySQL 

(String sql, Vector args) 

EJBObjectまたはEJBLocalObject1 
1 finderがホーム・インタフェースとコンポーネント・インタフェースのどちらで定義されているかによって決まります。

例1-3に、2つの事前定義のfinder（findByPrimaryKeyおよびfindManyBySQL）を定義するEJBHomeを示します。TopLinkは、これらのfinderの問合せ実装を提供します。

例1-3    事前定義のTopLink finderの指定

public interface EmpBeanHome extends EJBHome {
    public EmpBean create(Integer empNo, String empName) throws CreateException;
 
    /**
    * Finder methods. These are implemented by the container. You can
    * customize the functionality of these methods in the deployment
    * descriptor through EJB-QL.
    **/
     
    // Predefined Finders: <query> element in ejb-jar.xml not required
 
    public Topic findByPrimaryKey(Integer key) throws FinderException;
    public Collection findManyBySQL(String sql, Vector args) throws FinderException
 
}
デフォルトのTopLink finder

名前がfindBy<CMP-FIELD-NAME>（<CMP-FIELD-NAME>はBeanの永続フィールドの名前）と一致するエンティティBeanのホーム・インタフェースで定義されている各finderについて、TopLinkは、TopLink式フレームワークを使用するTopLink問合せ実装などのfinder実装を生成します。戻り型が単一のBean型である場合、TopLinkはoracle.toplink.queryframework.ReadObjectQueryを作成します。戻り型がCollectionの場合、TopLinkはoracle.toplink.queryframework.ReadAllQueryを作成します。これらのfinderは、他のfinderと同様にクライアントに公開できます。対応する問合せを指定する必要はありません。

例1-4に、デフォルトのfinder（findByEmpNo）を定義するEJBHomeを示します。TopLinkは、このfinderの問合せ実装を提供します。

例1-4    デフォルトのTopLink finderの指定

public interface EmpBeanHome extends EJBHome {
    public EmpBean create(Integer empNo, String empName) throws CreateException;
 
    /**
    * Finder methods. These are implemented by the container. You can
    * customize the functionality of these methods in the deployment
    * descriptor through EJB-QL.
    **/
     
    // Default Finder: <query> element in ejb-jar.xml not required
 
    public Topic findByEmpNo(Integer empNo);
}
カスタムTopLink finder

TopLink問合せおよび式フレームワークを利用して、Call、DatabaseQuery、主キー、Expression、EJB QL、ネイティブSQL、リダイレクトfinder（任意のヘルパー・クラスの静的メソッドとして定義する実装に実行を委任する）など、高度なfinderを定義できます。

EJB 2.1を使用してカスタムTopLink finderを作成するには、TopLink Workbenchで既存のtoplink-ejb-jar.xmlファイルを使用します（「TopLink Workbenchの使用方法」を参照）。

selectメソッドについて

エンティティBeanのselectメソッドは、コンテナ管理の永続性を備えたEJB 2.1エンティティBeanインスタンス内で内部的に使用する問合せメソッドです。selectメソッドを抽象エンティティBeanクラス自体の抽象メソッドとして定義し、EJB QL問合せを関連付けます。ホームまたはコンポーネント・インタフェースではクライアントにselectメソッドは公開しません。1つ以上のselectメソッドを定義すること、またはselectメソッドを定義しないことができます。関連付けるEJB QL問合せに基づいてselectメソッドの実装を提供するのはコンテナです。

通常は、ビジネス・メソッド内でselectメソッドをコールして、コンテナ管理の永続性フィールドの値またはコンテナ管理の関連性フィールドのエンティティBean参照を取得します。selectメソッドは、起動側ビジネス・メソッドのトランザクション属性で判断されるトランザクション・コンテキストで実行します。

selectメソッドには次のシグネチャがあります。

public abstract <ReturnType> ejbSelect<METHOD>(...) throws FinderException

selectメソッドは、起動されたエンティティBeanインスタンスの識別情報に基づいていませんが、エンティティBeanの主キーを引数として使用できます。これにより、特定のエンティティBeanインスタンスに論理的に範囲設定された問合せが作成されます。

EJB 2.1を使用している場合は、カスタムEJB QL selectメソッド（「EJB 2.1 EJB QL selectメソッドの実装」を参照）を定義でき、カスタムTopLink selectメソッド（「カスタムTopLink selectメソッド」を参照）を定義できます。

selectメソッドが返す型

selectメソッドの戻り型は、selectが起動されるエンティティBeanのタイプに制限されません。コンテナ管理の永続性またはコンテナ管理の関連性フィールドに対応する任意の型を返すことができます。

selectメソッドは、次の戻り型ルールに準拠している必要があります。

カスタムTopLink selectメソッド

EJB 2.1を使用して、カスタムTopLink selectメソッドを作成できます。

EJB 2.1を使用している場合は、TopLink問合せおよび式フレームワークを利用して、Call、DatabaseQuery、Expression、EJB QL、ネイティブSQLなど、任意のTopLink問合せおよび式フレームワーク機能を利用できる高度なselectメソッドを定義できます。詳細は、「TopLink Workbenchの使用方法」を参照してください。

メッセージドリブンBeanとは

メッセージドリブンBean（MDB）は、非同期メッセージ・コンシューマとして機能するEJB 3.0またはEJB 2.1 Enterprise Beanコンポーネントです。MDBにはクライアント固有の状態はありませんが、開いたデータベース接続や別のEJBへのオブジェクト参照などのメッセージ処理状態を含むことができます。クライアントは、MDBを使用して、Beanがメッセージ・リスナーとなっている送信先にメッセージを送信します。

OC4Jを使用すると、MDBを様々なメッセージ・プロバイダとともに使用できます（「MDBで使用できるメッセージ・サービス・プロバイダ」を参照）。次のように、MDBを既存のメッセージ・プロバイダに関連付け、必要な設定の多くをコンテナが処理します。

MDBの目的は、プール内に存在し、メッセージ・プロバイダからの受信メッセージを受け取り、処理することです。コンテナは、キューからBeanを起動して、キューからの受信メッセージを処理します。MDBを直接起動するオブジェクトはありません。MDBの起動は、すべてコンテナから指示されます。いったんコンテナがMDBを起動すると、他のEnterprise BeanまたはJavaオブジェクトを起動して、リクエストを続行することが可能です。

MDBは、対話状態を保存せず、複数の受信リクエストの処理に使用される点において、ステートレス・セッションBeanに似ています。MDBは、クライアントから直接受信したリクエストを処理するのではなく、キューに入れられたリクエストを処理します。図1-7に、このように、クライアントがリクエストをキューに入れる様子を示します。コンテナは、キューからリクエストを取り出し、そのリクエストをプール内のMDBに渡します。

図1-7    メッセージドリブンBean


画像の説明

この項の内容は次のとおりです。

詳細は、次を参照してください。

メッセージドリブンBeanのライフ・サイクル

図1-8に、メッセージドリブンBeanのライフ・サイクルを示します。@PostConstructなどのアノテーションは、EJB 3.0のメッセージドリブンBeanにのみ適用されます。

図1-8    EJB 2.1 MDBのライフ・サイクル


画像の説明

EJB 3.0（表1-18を参照）とEJB 2.1（表1-19を参照）のメッセージドリブンBeanのライフ・サイクルは同一です。違いは、ライフ・サイクル・コールバック・メソッドの登録方法です。

表1-18に、アノテーションを使用して定義できるEJB 3.0メッセージドリブンBeanのオプションのライフ・サイクル・コールバック・メソッドをリストします。EJB 3.0メッセージドリブンBeanでは、これらのメソッドを実装する必要はありません。

表1-18    EJB 3.0メッセージドリブンBeanのライフ・サイクル・メソッド 
アノテーション  説明 

@PostConstruct 

このオプションのメソッドは、Beanに対して最初のビジネス・メソッドを起動する前に、メッセージドリブンBeanに対して起動されます。これは、任意の依存性注入がコンテナにより実行された後の時点です。 

@PreDestroy 

このオプションのメソッドは、インスタンスがコンテナにより削除されているときにメッセージドリブンBeanに対して起動されます。通常、インスタンスは保持していたリソースを解放します。 

表1-19に、javax.ejb.MessageDrivenBeanインタフェースでの指定に従って、メッセージドリブンBeanが実装する必要のあるEJB 2.1ライフ・サイクル・メソッドをリストします。EJB 2.1メッセージドリブンBeanでは、最低でも、すべてのコールバック・メソッド用に空の実装を用意する必要があります。

表1-19    EJB 2.1メッセージドリブンBeanのライフ・サイクル・メソッド 
EJBメソッド  説明 

ejbCreate 

コンテナは、Beanの作成直前にこのメソッドを起動します。メッセージドリブンBeanは、このメソッドでは何も行いません。 

ejbRemove 

コンテナは、MDBを破棄する前にこのメソッドを起動します。このメソッドを使用して、ファイル・ハンドルなどの外部リソースのクローズなど、必要なクリーンアップを実行します。 

詳細は、次を参照してください。

メッセージ・ドリブン・コンテキストとは

OC4Jは、メッセージドリブンBeanインスタンスのjavax.ejb.MessageDrivenContextを維持し、このメッセージドリブン・コンテキストをBeanに対して使用可能にします。Beanは、メッセージドリブン・コンテキスト内のメソッドを使用して、コンテナへのコールバック・リクエストを送信できます。

また、EJBContextから継承されたメソッドを使用できます（「EJBコンテキストとは」を参照）。

詳細は、次を参照してください。

使用するEnterprise Beanのタイプ

この項の内容は次のとおりです。

使用するセッションBeanのタイプ

ステートレス・セッションBeanは、主に、頻繁な短いリクエストを処理するためのBeanのプールを持つ中間層アプリケーション・サーバーに使用されます。

Bean管理の永続性を使用する場合とコンテナ管理の永続性を使用する場合

表1-20で、具体的に、BMPとCMP両方の定義、およびそれらのプログラム面での違いと宣言の違いを示します。

表1-20    Bean管理の永続性とコンテナ管理の永続性の比較 
管理項目  Bean管理の永続性  コンテナ管理の永続性 

永続性の管理 

永続性管理を、ejbStore、ejbLoad、ejbCreateおよびejbRemove EntityBeanメソッド内に実装する必要があります。これらのメソッドには、永続データの格納およびリストアのためのロジックが含まれている必要があります。

たとえば、ejbStoreメソッドの場合、エンティティBeanのデータを適切なデータベースに格納するためのロジックが含まれている必要があります。そうでない場合、データが失われる可能性があります。  

永続データの管理をユーザーが行う必要がありません。つまり、コンテナが、Beanのかわりに永続マネージャを起動します。

コミット前のデータの準備、またはデータベースからリフレッシュされた後のデータ操作には、ejbStoreおよびejbLoadを使用します。コンテナは、必ず、コミットの直前にejbStoreメソッドを起動します。さらに、CMPデータをデータベースから再インスタンス化した直後にejbLoadメソッドを起動します。 

使用可能なfinderメソッド 

findByPrimaryKeyメソッドおよびその他のfinderメソッドが使用可能です。 

findByPrimaryKeyメソッドおよびその他のfinderメソッド句が使用可能です。 

コンテナ管理の永続性フィールドの定義 

N/A 

EJBデプロイメント・ディスクリプタ内で必須。主キーは、コンテナ管理の永続性フィールドとしても宣言する必要があります。 

リソース格納先へのコンテナ管理の永続性フィールドのマッピング 

N/A 

必須。永続マネージャによって異なります。 

永続マネージャの定義 

N/A 

Oracle固有のデプロイメント・ディスクリプタ内で必須。OC4JではTopLink永続性マネージャがデフォルトで使用されます。 

CMPでは、独自の低レベルJDBCベースの永続性システムを作成しなくても、Java EEでサポートされるアプリケーション・サーバーおよびデータベースにEJBの状態を保存できるEJB 2.0仕様にコンポーネントを構築できます。

BMPでは、追加のコーディングやサポート作業を負担することでアプリケーションの永続性レイヤーを調整できます。

詳細は、次を参照してください。

データベース・リソースの競合の回避

OC4J、TopLink EJB 3.0 JPA永続性プロバイダおよびEJB 2.1永続性マネージャは、トランザクション分離（「トランザクション分離」を参照）と同時実行性モード（「同時実行性（ロック）モード」を参照）の組合せを使用して、データベース・リソースの競合を回避し、データベース表への同時アクセスを許可します。

トランザクション分離

同じデータに対する同時（パラレル）トランザクションが対話を許可される程度は、構成されているトランザクション分離のレベルによって決まります。ANSI/SQLは、表1-21に示すように、データベース・トランザクション分離の4つのレベルを定義します。各レベルには、パフォーマンスと次のような望ましくないアクションの防止との間にトレードオフがあります。

デフォルトでは、OC4J、TopLink EJB 3.0 JPA永続性プロバイダおよびEJB 2.1永続性マネージャは、コミット読取りトランザクション分離を提供します。

トランザクション分離モードを構成するには、TopLink EJB 3.0 JPA永続性プロバイダまたはEJB 2.1永続性マネージャをカスタマイズする必要があります。

詳細は、次を参照してください。

同時実行性（ロック）モード

OC4Jでは、EJB 3.0エンティティおよびコンテナ管理の永続性を備えたEJB 2.1エンティティBean内でのリソースの競合およびパラレル実行を処理するため、同時実行性モードも提供されます。

Bean管理の永続性を備えたエンティティBeanは、Bean実装自体内でリソースのロックを管理します。

同時実行性モードには、次のものが含まれます。

これらの同時実行性モードはBeanごとに定義され、トランザクション境界に適用されます。

EJB 3.0のデフォルトでは、JPA永続性マネージャにより、データ整合性の確保はアプリケーションの役割であるとみなされます。@Versionアノテーションを使用してバージョン・フィールドを指定し、JPA管理のオプティミスティック・ロックを有効化することをお薦めします。

EJB 2.1のデフォルトでは、TopLink永続性マネージャは、オブジェクト変更がコミットされるたびにTopLinkにより更新されるコード生成の数値バージョン・フィールドを使用してオプティミスティック・ロックを実行します。

別の方法で同時実行性モードを構成するには、TopLink EJB 3.0 JPA永続性プロバイダまたはEJB 2.1永続性マネージャをカスタマイズする必要があります。

詳細は、次を参照してください。

戻る 次へ
Oracle
Copyright © 2002, 2008 Oracle Corporation.
All Rights Reserved.
目次
目次		 索引
索引