WebSphere Application Server for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

アクセス・インテントに関するトラブルシューティングのヒント

アクセス・インテントを含む、次の FAQ (よくある質問) に回答します。

アクセス・インテント・ポリシーをまったく適用していません。 アプリケーションは DB2 データベースでは正常に実行されますが、Oracle データベースの場合には、 「com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1001E: No such DataAccessSpec :FindAllCustomers. The backend datastore does not support the SQLStatement needed by this AccessIntent: (pessimistic update-weakestLockAtLoad)(collections: transaction/25) (resource manager prefetch: 0) (AccessIntentImpl@d23690a).」というメッセージが出て失敗します。 なぜでしょうか。

アクセス・インテントを構成していない場合、すべてのデータが、デフォルトのアクセス・インテント・ポリシー (wsPessimisticUpdate-WeakestLockAtLoad) のを使用してアクセスされます。DB2 では、最も弱いロックが共用です。一方、Oracle データベースの場合、最も弱いロックは更新ロックです。つまり、SQL 照会には FOR UPDATE 文節が含まれている必要があります。 この問題を回避するためには、オプティミスティック並行性をサポートするアクセス・インテント・ポリシーの適用を試みてください。

finder メソッドを呼び出すと、実行時に InconsistentAccessIntentException が戻されます。 なぜでしょうか。

メソッド・レベルのアクセス・インテント・ポリシーを使用して、Bean インスタンスが ロードされる際の制御を強化した場合に、このような症状が出ることがあります。 この例外は、以前、同一トランザクション内にそのエンティティー Bean がロードされたことを示しています。 これは、multifinder メソッドを呼び出して、アクセス・インテント・ポリシー X が適用された Bean インスタンスを戻し、次に、アクセス・インテント・ポリシー Y が適用された findByPrimaryKey メソッドを呼び出して 2 番目の Bean を再度ロードしようとしているときに発生する可能性があります。 両方のメソッドには、同じアクセス・インテント・ポリシーが適用されている必要があります。

同様に、ファインダー上で構成されたアクセス・インテント・ポリシーを使用するトランザクションに、 エンティティーが一度ロードされた場合は、コンテナー管理関係 (CMR) accessor メソッドが呼び出され、 そのメソッドによって、そのエンティティーのデフォルト・アクセス・インテントを使用してロードするように構成されたエンティティー Bean が戻されることがあります。

この問題を回避するには、コードによって、同一トランザクション内で、異なるアクセス・インテント・ポリシーを使用して同じ Bean インスタンスが 2 度ロードされないようにしてください。 どうしても必要な場合を除き、メソッド・レベルのアクセス・インテントは使用しないでください。

コンテナー管理関係内には 2 つの Bean があります。 1 番目の Bean で findByPrimaryKey() を呼び出し、その後に戻されたインスタンスで CMR accessor メソッド getBean2( ) を呼び出します。 この時点で、InconsistentAccessIntentException が戻されます。 なぜでしょうか。

おそらく、先読みを使用しているのでしょう。1 番目の Bean をロードしたとき、2 番目の Bean が、1 番目の Bean に対する finder メソッドに適用されているアクセス・インテント・ポリシーにロードされるようにしました。 ただし、1 番目の Bean から 2 番目の Bean への CMR accessor メソッドは、異なるアクセス・インテント・ポリシーによって構成されています。CMR accessor メソッドは、そのようには見えませんが、実際は finder メソッドです。ランタイム環境は、永続ストアから既に読み取ったインスタンスに関するアクセス・インテントを変更しようとしているかのように振る舞います。

この問題を回避するためには、先読みヒント内で構成された Bean をすべて、 先読みヒントが提供される Bean と同じアクセス・インテント・ポリシーを使用してロードするようにします。

2 番目の Bean には、1 対多の関係を持つ Bean があります。 1 番目の Bean には、ペシミスティック/更新インテント・ポリシーが適用されています。1 番目の Bean の集合に 2 番目の Bean のインスタンスを 追加しようとすると、UpdateCannotProceedWithIntegrityException が戻されます。なぜでしょうか。

2 番目の Bean には、 おそらく読み取りインテント・ポリシーが適用されています。2 番目の Bean を 1 番目の Bean の集合に追加する場合は、1 番目の Bean の状態が更新されているのではなく、2 番目の Bean の状態が暗黙的に変更されています(2 番目の Bean には、変更された 1 番目の Bean への外部キーが含まれています)。

この問題を回避するには、実行時に関係を変更する予定がある場合、関係の両端に更新インテント・ポリシーが適用されるようにしてください。




関連概念
アクセス・インテント・ポリシー
並行性制御
関連タスク
アクセス・インテント・ポリシーの使用
関連資料
アクセス・インテントの例外
アクセス・インテントのアセンブリー設定
アクセス・インテント -- 分離レベルおよび更新ロック
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 5:46:14 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.iseries.doc/info/iseries/ae/rejb_axifaq.html