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

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

アクセス・ポリシーが適用されていない場合に Oracle データベースが失敗する

アクセス・インテント・ポリシーが適用されておらず、アプリケーションは 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 とのコンテナー管理関係に InconsistentAccessIntentException が表示される

コンテナー管理関係内には 2 つの Bean があります。 1 番目の Bean で findByPrimaryKey メソッドを呼び出し、その後に戻されたインスタンスで getBean2 メソッドを呼び出してから CMR accessor メソッドを呼び出すと、InconsistentAccessIntentException が表示されます

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

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

2 番目の Bean に対して 1 対多のリレーションシップを持つ Bean は、エラーを表示します。

2 番目の Bean に対して 1 対多のリレーションシップを持つ Bean は、2 番目の Bean のインスタンスが 1 番目の Bean のコレクションに追加されると、UpdateCannotProceedWithIntegrityException エラーを表示します。

2 番目の Bean に対して 1 対多のリレーションシップを持つ Bean は、2 番目の Bean のインスタンスが 1 番目の Bean のコレクションに追加されると、UpdateCannotProceedWithIntegrityException エラーを表示します。 1 番目の Bean には、ペシミスティック/更新インテント・ポリシーが適用されています。

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

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


トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rejb_axifaq
ファイル名:rejb_axifaq.html