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

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

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

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

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

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

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

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

エンティティー Bean のアクセス・インテント・ポリシーを変更するには、アセンブリー・ツールを使用して Bean レベルを設定できます。 手順は、Bean へのアクセス・インテント・ポリシーの適用を参照してください。


トピックのタイプを示すアイコン 概念トピック



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