問題タブ [deadlock]

時々デッドロックする Web アプリケーションに問題があります

関連するクエリは 3 つあります。2 人がテーブルを更新しようとしています

そして、1つはテーブルに挿入しようとしています

デッドロック グラフは、ページ ロックと交換イベントの一種の循環配置を示しており、2 つの更新クエリは同じサーバー プロセス ID を持っています。

この問題を解決する方法について誰かがアイデアを持っている場合は、それを高く評価してください。

誰かがそれを見る必要がある場合に投稿できるデッドロック グラフがあります。

ありがとうカールR

私はSun jdk 1.5 ThreadPoolExecutor（24、24,60、TimeUnit.SECONDS、新しいLinkedBlockingQueue（））を使用しています。soemtime jdbツールを使用して、スレッドプール内のすべてのスレッドのステータスが「モニターで待機中」であることを確認します。コードは次のとおりです。

"synchronized (key.intern()) " に問題はありますか?

jdb ツールを使用して次の情報を取得します。24 スレッドのステータスは「モニターで待機中」です。これは、24 スレッドが「key.intern()」でデッドロックしていることを意味します。

(java.lang.Thread)0x28 pool-3-thread-2 モニターで待機中

(java.lang.Thread)0x27 pool-3-thread-3 モニターで待機中

(java.lang.Thread)0x1b pool-3-thread-4 モニターで待機中

(java.lang.Thread)0x1a pool-3-thread-5 モニターで待機中

(java.lang.Thread)0x19 pool-3-thread-6 モニターで待機中

(java.lang.Thread)0x18 pool-3-thread-7 モニターで待機中

(java.lang.Thread)0x17 pool-3-thread-8 モニターで待機中 ...

結果は次のとおりです。マルチスレッド環境では、Sting intern() メソッドがデッドロックになる可能性があります。

SQL 2005 データベース (64 ビット) で発生しているデッドロックを追跡しようとしています。現在、スナップショット分離は有効になっていません。

tf-1204 をオンにすると、以下の出力が表示されました。

この出力から、ノード 1 はデータを選択し、#temp テーブルの値のみを変更するストアド プロシージャであることがわかります。

ノード 2 は別のストアド プロシージャで、1 行のデータに対して単純な主キー ベースの更新を行います。

私が判断できないのは、ここで競合していた実際のリソースです。10:72057594060734464 と 10:72057594038910976 のキーでデータベースを特定できますが、これらのオブジェクト ID は object_name で解決できません。実際、これらは int 値である必要があるため、これらの大きな数値がどこから来ているのかわかりません。

この問題を調査したところ、Activity Monitor から Object ID についても同様の値を取得できました。

これらのオブジェクト識別子を解決するにはどうすればよいですか?

デッドロック tf-1204 の出力は次のとおりです。

私はスレッドが初めてで、助けが必要です。新しいレコードを挿入するのに非常に長い時間 (つまり、50 ～ 75 秒) かかるデータ入力アプリがあります。したがって、私の解決策は、ThreadPool を介して挿入ステートメントを送信し、挿入の実行中に新しいレコード ID を返す挿入中に、ユーザーがレコードのデータの入力を開始できるようにすることでした。私の問題は、その挿入から新しい ID が返される前に、ユーザーが保存を押すことができることです。

安全に保存できるときに、そのスレッドからのイベントを介してtrueに設定されるブール変数を入れてみました。それから入れました

それは悪い考えだと思います。トレッドが戻る前に保存メソッドを実行すると、スタックします。

だから私の質問は：

1. これを行うより良い方法はありますか？
2. ここで何が間違っていますか？

助けてくれてありがとう。
ダグ

詳細については編集してください：

非常に大きな (最大サイズに近づいている) FoxPro データベースへの挿入を実行しています。このファイルには、約 200 のフィールドとほぼ同じ数のインデックスがあります。
そして、あなたが尋ねる前に、いいえ、私がいる前にここにあったように、それの構造を変更することはできず、それを打つ大量のレガシーコードがあります。最初の問題は、新しい ID を取得するには、最初にテーブル内の max(id) を見つけてから、それをインクリメントしてチェックサムする必要があることです。これには約 45 秒かかります。次に、最初の挿入は、その新しい id と enterdate フィールドの単純な挿入です。このテーブルは DBC に入れられない/入れられないので、自動生成 ID などを除外します。

@joshua.ewer
あなたは正しいプロセスを持っています。短期的には保存ボタンを無効にするだけだと思いますが、それをキューに渡すというあなたのアイデアを検討します。確認すべき MSMQ に関する参考資料はありますか?

.NET で C# を使用すると、次のコードでデッドロックが発生しますか?

これはおそらく非常に基本的なものなので、ご容赦ください (一方で、おそらく素敵な光沢のあるカットアンドドライの答えがあるでしょう!)。

現在、デッドロックの問題を診断しています。実際、セッションの 1 つが別のセッションによってブロックされていることがわかります。(デッドロックのもう一方の端は、反対の順序で互いに待機している Java スレッドです。) Management Studio のプロセス エクスプローラーでプロセスの詳細を表示すると、ブロックされたセッションの SQL が表示されますが、ブロックされたセッションの SQLのみが表示されます。 「EXEC sp_unprepare 807」として。

これは準備されたステートメントに関連していることを理解したので、これ自体に動揺していません。ただし、実際の SQL が何であるかを知りたいので、コードベースのどこに疑わしい目を向けるべきかがわかります。では、この時点で、これをこのスレッドによって実行された実際の SQL に関連付ける最良の方法は何でしょうか? 準備済みステートメントの SQL へのマッピングを検索できるシステム テーブルはありますか? おそらく、呼び出しを保持することが期待されるセッションの最後のn SQL ステートメントを格納するテーブルでしょうか? prepareこのセッションでプリペアド ステートメントを完全に無効にするデータベース ドライバー接続に設定できるフラグはありますか?

この問題に対する代替アプローチがより良い方法である場合は、それを歓迎します (基本的に、テーブルを変更した後にコミットに失敗している Java コードがいくつかあると強く疑っています。そのための SQL を知りたいです)私はそれがどこにあるかを見つけます）。

次の C# クラスは、マルチスレッド環境で使用されます。実際のコードの大部分を削除しました。この問題は、MethodA と MethodB をほぼ同時に呼び出すと発生します。IsDepleted プロパティのロックの順序は問題を解決しません。IsDepleted プロパティから lock(WaitingQueue) を削除するとデッドロックが解決されますが、この解決策では、別のスレッドが WaitingQueue.Count == 0 ステートメントと Processing.Count == 0 ステートメントの間で WaitingQueue に項目を追加/削除するときに問題が発生します。

SQL Server 2005 を使用する .NET アプリケーションのデッドロックのトラブルシューティングを手伝っています。以下のトレースからの XML データがあります。

私を本当に困惑させているのはPK_Exp_Experience_PriorFirm、トランザクション分離レベルが読み取りコミットされている場合の RangeX-X ロックです。

私が読んだことはすべて、トランザクション分離レベル「シリアル化可能」を使用しているキー範囲ロックのみを取得することを示しています。これまでのところ、分離レベルを read commit 以外に設定しているアプリケーションの場所を見つけることができません。また、以下の XML は、read commit を使用していることを示しています。

しかし、read-committed を使用している場合、キー範囲ロックが存在することをトレースがどのように示しているかわかりません。誰もがそれがどのように起こっているのかについて考えを持っていますか?

このエラーは非常に頻繁に発生しますが、実稼働環境にあるアプリケーションの2ページで一貫して発生するわけではありません。以下のエラーのスクリーンショットをいくつか示します。

トランザクション（プロセスID XX）がロックでデッドロックされました| 別のプロセスとの通信バッファリソースであり、デッドロックの犠牲者として選択されています。トランザクションを再実行します。

このエラーを解決するためのアプローチはどうあるべきか。dbサーバーはSQLServer2005です。