EJB データ・メディエーター・サービスのプログラミング考慮事項
本製品が提供する Enterprise JavaBeans (EJB) データ・メディエーター・サービス (DMS) を利用してアプリケーションの作成を開始する場合は、以下の項目を考慮してください。
EJB プログラミング・モデル
EJB プログラミング・モデルのサブセットのみが、EJB データ・メディエーター・サービスによってサポートされています。
- EJB コレクション・パラメーターを使用して、EJB インスタンスから
データを検索するとき、または applyChanges を使用して EJB インスタンスをアップデートするとき:
- EJB DMS はエンタープライズ Bean のローカル・インターフェースを使用します。 コンテナー管理パーシスタンス (CMP) フィールドの getter および setter 呼び出しは、 照会式で使用される EJB メソッドと同様に、ローカル・インターフェースへプロモートされなければなりません。
- EJB を作成するメディエーターの場合、EJB ホームで定義された唯一
の引数メソッドとして 1 次キー・クラスを使用した create メソッドがなければなりません。
このようなメソッドがない場合、作成操作を扱うアダプターを提供しなければなりません。
また、EJB 用に定義された EJBLocalHome インターフェースは、(create
メソッドに加えて) 以下のメソッドを含まなければなりません。
findByPrimaryKey(<key class>) remove (java.lang.Object) create (<key class>)
- データベースから直接 applyChanges メソッドを起動すると、以下のことが発生します。
- コンテナー更新をバイパスします。 トランザクション終了および適切なコンテナー・キャッシュ・オプションの使用によって、可能な限り早く最新表示を強制します。
- EJB コンテナー管理関係 (CMR) 保守をバイパスします。 データベース RI に依存して、これらの関連が DataGraph 内に取得されな いように保守する必要があります。
- CMP フィールドは、許可タイプでなければなりません。 これらのタイプのリストについては、EJB メディエーター照会構文 を参照してください。
- EJB converters/composer を使用するユーザー定義タイプの CMP フィールドは、サポートされません。
以下のテーブルは、EJB DMS によってサポートされない EJB プログラミング・モデル内の制限を表示しています。
DB から直接検索 | EJB コンテナーから検索 | DB へ直接更新 | EJB を介した更新 | |
---|---|---|---|---|
EJB パーシスタンス継承 | いいえ | いいえ | いいえ | いいえ |
コンバーターを持つ EJB CMP フィールド | いいえ | はい | いいえ | はい |
トランザクションの
- すべてのメディエーター呼び出し (create を含む) は、トランザクション・スコープ (ユーザー・トランザクションまたはコンテナー・トランザクション) 内で行う必要があります。 それぞれ異なるメディエーター呼び出し (create、getGraph、および applyChanges を含む) は、同じトランザクション内で呼び出す必要はありません。 実際、呼び出しはほとんどの場合個別のトランザクションで行われます。
アクセス・インテント
- メディエーター照会が Abstract Schema Name (ASN) を使用して EJB を参照する際は、データが直接データベースより検索されます。 データ・ソース接続に使用されるアクセス・インテントおよび分離レベルは、EJB 動的照会アクセス・インテントのアプリケーション・プロファイルで指定されたアクセス・インテントです。 DataGraph は、切断されたプログラミング・モデルで使用することを意図しているため、ご使用のアプリケーションのオプティミスティック・アクセス・インテントを定義することをお勧めします。
- メディエーターが EJB コレクションを使用してデータを検索する際に、EJB の活動化が必要な場合は、アプリケーション・プロファイルで指定されたアクセス・インテントが使用されます。
- applyChanges の間、変更をデータベースに適用する前に、Optimistic Concurrency Control を使用して DataObject のフィールドを検証します。
アップデートは通常、検索とは別のトランザクションの下で処理されます。
したがって、更新が失われることを防ぐために、別のトランザクションがデータをアップデートしていないかどうかを検証する必要があります。
EJB から RDB へのマッピングを定義する場合、オプティミスティック述部として 1 つ以上の EJB フィールドを指定することができます。
これらのフィールドは、現在のデータベース値を DataGraph 変更ログの古い値と比較することにより、検証用として使用されます。
検証が正常に終了すると、フィールドの現行値がデータベースに書き込まれます。
比較が false を戻し更新が失敗すると、例外が発生します。
これらはすべて、次の例のように別の述部を追加した単一のアップデート・ステートメントで実行されます。
optimisticPredicate フィールドは myColumn1 です。
update myTable set myColumn1="new value1", myColumn2="new value2"where myKey="key value" and myColumn1="old value1"
- applyChanges が EJB コンテナーを介して行われると、エンタープライズ Bean の現行値は、オプティミスティック述部フィールドの古い値と比較されます。 値が等しくない場合は、例外が発生します。
- optimisticPredicates として 1 つ以上の EJB フィールドを定義した場合、SDO をアップデート可能にするには、optmisticPredicate フィールドの少なくとも 1 つをデータ・オブジェクトに取り出す必要があります。 これを行わないと、applyChanges が例外を戻します。 このフィールドは、呼び出し元またはデータベース・トリガーのいずれかで更新する必要があります。メディエーターはフィールドの増分または設定を自動的には行いません。
- すべてのフィールドが検証されるわけではありません。 EJB-RDB マッピングで optimisticPredicate とマーク付けされたフィールドのみ検証されます。
- EJB マッピング・ツールは optimisticPredicate フィールドがない可能性も想定していることにご注意ください。 この場合、メディエーターは検証なしで更新を実行します。
- 作成および削除の操作は、オプティミスティック述部フィールドを使用しません。
- EJB インスタンスを使用して変更を適用する場合は、最初に EJB を活動化する必要があります。 この場合、EJB メソッドに関連付けられた適切なアクセス・インテントが適用されます。 ペシミスティック・アクセス・インテントを持つプロファイルで applyChanges を実行することをお勧めします。 そうしないと、オプティミスティック並行性ロジックが 2 回呼び出されます。 1 回目はデータ・オブジェクト値を EJB にコピーするとき、2 回目はパーシスタンス・マネージャーがデータベース・レコードに対して EJB フィールドの古い値を比較するときです。
- データベースから直接検索するときにメディエーターによって使用さ れるアクセス・インテントは、最初の照会ステートメント内で指定された EJB のために定義されたデフォルトのアクセス・インテントです。
ベスト・プラクティス
- 1 つのメディエーター・インスタンス上で getGraph を呼び出し、返された DataGraph を更新した後に、別のメディエーター・インスタンス上で applyChanges を呼び出すことができます。 しかし、同じメディエーター・インスタンスは必要ありませんが、同じ 照会形状 は必要です。 照会形状は、 照会ステートメントの番号および配列、SELECT および FROM 文節内で指定さ れたフィールドおよび関係などです。
- 可能であれば、createMediator への繰り返し呼び出しを避けてください。 パラメーター化照会を使用し、また異なるパラメーター値で受け渡すために getGraph を使用してください。