このエラーは非常に頻繁に発生しますが、実稼働環境にあるアプリケーションの2ページで一貫して発生するわけではありません。以下のエラーのスクリーンショットをいくつか示します。
トランザクション(プロセスID XX)がロックでデッドロックされました| 別のプロセスとの通信バッファリソースであり、デッドロックの犠牲者として選択されています。トランザクションを再実行します。
このエラーを解決するためのアプローチはどうあるべきか。dbサーバーはSQLServer2005です。
このエラーは非常に頻繁に発生しますが、実稼働環境にあるアプリケーションの2ページで一貫して発生するわけではありません。以下のエラーのスクリーンショットをいくつか示します。
トランザクション(プロセスID XX)がロックでデッドロックされました| 別のプロセスとの通信バッファリソースであり、デッドロックの犠牲者として選択されています。トランザクションを再実行します。
このエラーを解決するためのアプローチはどうあるべきか。dbサーバーはSQLServer2005です。
デッドロックのトラブルシューティングに関する聖書は次のとおりです。
http://blogs.msdn.com/bartd/archive/2006/09/09/Deadlock-Troubleshooting_2C00_-Part-1.aspx
Brad McGeheeによるこの記事は、始めるのに適した場所です。
こちらもご覧ください:プロアクティブなデッドロック通知
エラーが発生している間は、デッドロック プロファイル トレースを実行する必要があります。Brad McGehee による記事は概要です。問題のある 2 つのプロセスを特定する必要があります。その後、2 ページのコードを確認して、どの SQL コマンドがどのくらいの頻度で発行されているかを確認します。ほとんどの場合、実行中の SQL コードを確認し、実行頻度を把握するだけで競合をすばやく特定できることがわかりました。修正には時間がかかる場合があります...
エラー メッセージが示すように、プログラムにトランザクションを再試行させることができます。
ただし、トランザクションがどの程度「アトミック」であるかに大きく依存します。つまり、デッドロックした場合、他のプロセスが目的の行を正常に更新した可能性があります。これらの状況で行に更新を適用することは意味がありますか?
少なくとも、より適切なエラー メッセージをユーザーに表示します (「別のユーザーが、更新しようとしていた xxxx を変更しました。新しい値を確認して、もう一度やり直してください。」)