WebSphereのデッドロック解析

WebSphereのInfoCenterに載っていたデッドロック解析

http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp


COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "2". SQLSTATE=40001

この問題は、アプリケーションが原因で DB2 のデッドロックが発生した場合、特に DB2 データ・ソースへのアクセス中に、次のようなエラーが発生した場合です。 

ERROR CODE: -911
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N  The current transaction has been rolled back because of a deadlock or timeout.Reason code "2".  SQLSTATE=40001

問題を診断するには、以下のようにします。 

以下の DB2 コマンドを実行する。

db2 update monitor switches using LOCK ON 
db2 get snapshot for LOCKS on dbName > directory_name\lock_snapshot.log 

ここで、directory_name\lock_snapshot.log には DB2 ロック情報が含まれます。 

db2 update monitor switches using LOCK OFF

 を実行して、モニターのロックをオフにする。 

デッドロックがあるかどうかを確認するには、以下のようにします。

ロック待機状況を持つアプリケーション・ハンドルを探し、次に「ロックを保留しているエージェントの ID」を探して、そのエージェントの ID を確認する。 
そのハンドルに移動し、そのハンドルがロック待機状況を持っているか、およびそのハンドルに対するロックを保留するエージェントの ID を持っているかを確認する。それが以前のものと同じエージェント ID である場合は、循環ロック (デッドロック) であることが分かります。 

この問題を解決するには、以下のようにします。 

アプリケーションを検査し、並行アクセスが必要でない場合は、制限の少ない分離レベルを使用する。 
accessIntent を小さくするとデータ保全性問題が生じることがあるので注意してください。 
DB2/UDB バージョン 7.2 以前のリリースの場合、 
Bean メソッド上で定義される accessIntent が制限的すぎる場合 (例えば PessmisticUpdate など) は、
不要なデッドロックを排除するために DB2 コマンド行ウィンドウから DB2_RR_TO_RS フラグを設定することができます。 
DB@_RR_TO_RS を設定すると、以下のような 2 つの影響を与えます。

選択した分離レベルが RR である場合、これは効果的に RS へとダウングレードされます。 
別の分離レベルを選択し、DB2_RR_TO_RS 設定をオンにすると、スキャンは、その行がスキャン対象であっても、
削除済みでコミットされていない行はスキップします。
スキップ動作は、RR、読み取り固定 (RS)、およびカーソル固定 (CS) 分離レベルに影響を与えます。 

例えば、トランザクション A が column1=10 の行を削除し、
トランザクション B が column1>8 および column1<12 にスキャンを行うというシナリオがあるとします。 
DB2_RR_TO_RS をオフにした場合、トランザクション B はトランザクション A がコミットまたはロールバックするまで待機します。
トランザクション A がロールバックすると、column1=10 の行は、トランザクション B の照会の結果セットに組み込まれます。 
DB2_RR_TO_RS をオンにした場合、トランザクション B はトランザクション A がコミットまたはロールバックするまで待機しません。トランザクション B は、削除された行を含まない結果を即時に受け取ります。 
DB2_RR_TO_RS を設定すると、ロック動作が効果的に変更され、デッドロックが回避されます。

End of FILE.