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

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

ロック・アップグレードが原因のデータベース・デッドロック

ロック・アップグレードによるデータベース・デッドロックを回避するために、 エンティティー Bean のアクセス・インテント・ポリシーを、 デフォルトの wsPessimisticUpdate-WeakestLockAtLoad から wsPessimisticUpdate に変更するか、 あるいはオプティミスティック・ロック・アプローチを使用することができます。

データベース内のデータに並行してアクセスする場合、アプリケーションは、 データの保全性を確保するために必要なデータベース・ロックを認識し、 それに備える必要があります。

エンティティー Bean が findByPrimaryKey (デフォルトではデータベースで「読み取り」ロックを取得) を実 行した後、そのエンティティー Bean が同一トランザクション内で更新されると、 ロック・アップグレード (「排他的」へ) が発生します。

この状態が複数のスレッドで同時に起こると、 デッドロックが生じることがあります。これは、複数の「読み取り」ロックを同時に取得できるのに対して、 「排他的」ロックは他のすべてのロックが除去されたときに 1 つ取得できるだけであるためです。 すべてのトランザクションがロック・アップグレードをこのシナリオで試行しているため、 この 1 つの「排他的」ロックを取得することはできません。

この問題を回避するために、エンティティー Bean のアクセス・インテント・ポリシーを、 デフォルトの wsPessimisticUpdate-WeakestLockAtLoad から wsPessimisticUpdate に変更することができます。 アクセス・インテントをこのように変更すると、アプリケーションから WebSphere およびデータベースに、 トランザクションがエンタープライズ Bean を更新することが通知されるため、 findByPrimaryKey ですぐに「更新」ロックが取得されます。これによって、 あとで更新を実行するときにロック・アップグレードを避けることができます。

アクセス・インテント・ポリシーを定義するのに望ましい方法は、 エンティティー Bean 全体のアクセス・インテントを変更することです。 findByPrimaryKey メソッドのアクセス・インテントを変更することもできますが、 これはバージョン 6.0 では推奨されていません。 (例えばエンティティー Bean が読み取り専用のトランザクションに含まれている場合は、 個々のメソッドのアクセス・インテントを変更することもできます。)

あるいは、オプティミスティック・アプローチを使用する方法もあります。 このアプローチでは、findByPrimaryKey メソッドに「読み取り」ロックが含まれていないので、 ロック・アップグレードは発生しません。ただし、 この場合はロールバックが生じる可能性があり、それを処理するためには、 アプリケーションがこのアプローチ用にコーディングされている必要があります。 オプティミスティック・ロックは、実は、 通常ではデータベースの競合が予想されないアプリケーションのためのものです。

エンティティー Bean のアクセス・インテント・ポリシーを変更するには、アセンブリー・ツールを使用して、 EJB デプロイメント記述子の「アクセス」タブで、 「エンティティー 2.x のデフォルト・アクセス・インテント (Bean レベル)」を設定します。Bean へのアクセス・インテント・ポリシーの適用を参照してください。




関連概念
アクセス・インテント・ポリシー
並行性制御
関連タスク
アクセス・インテント・ポリシーの使用
Bean へのアクセス・インテント・ポリシーの適用
関連資料
アクセス・インテント -- 分離レベルおよび更新ロック
エンタープライズ 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/cejb_ailu.html