必要性があるので、デッドロックを解決するために、デッドロックに関連する知識のいくつかの知識を持っている必要があります、非DBAの特定の深さを理解する必要はありませんが、基本的な概念だけでなく、分析の一般的な方法を知っていることができる、すべての後に、食べるためにこれに依存していない、特に詳細な領域に到達する必要はありません。ここで私は、MicrosoftのMVPは、システムのブログを書いた発見、私はデッドロックが非常に重要であることを理解し、ここでプログラムによって使用されるデッドロックに私の現在のソリューションを共有することです。
ストレステストのためのビジネスシナリオ
1.アナログユーザーが申請
a) 関係するテーブル
i. マスターテーブルを申請し、申請ごとに1つのデータを生成します。
ii.申請医師の内訳（1申請で複数の医師を申請する場合、1申請で100人の医師を申請する場合を含む）。
iii. 個々の医師の内訳、医師1人につき1つの内訳
要約すると、1つのアプリケーションを作成するには201個のデータを挿入する必要があります。
(b) アプリケーション・ロジック
i. 最初のセーブコール
ii.次にサブミッションロジックが実行されます。
歴史的な理由によって引き起こされる様々な論理的な検証は、常にデータを提出するときにダブルチェックを行うなど、データがあるかどうか、ロジックの重複行は、ここで繰り返し医師のテーブルと2つのアプリケーションの詳細サブテーブルの医師の詳細のアプリケーションを読み取ります。これは、デッドロックの主な理由は、このシナリオは、すでに同じテーブルの同時読み取りと変更を満たしています。これに加えて、データは、いくつかのステータスの追跡情報、電子メールの送信など、他のテーブルに挿入されます。
このもともと同じアクションの要件に対処するために2つの論理に分割された理由については、法律の元の設計者がテストされている、これらの論理は、EntityFramworkクエリの書き込みの様々な含まれている、それは効果的な最適化を行うことは困難です。
2.圧力設定
a) 同時に8ユーザー
(b) 1分ごとに5人の追加ユーザー
[]
今までに学んだことのない道です：
トランザクションの分離レベルをコミットされていない読み込みに下げてもデッドロックがなくなるわけではありませんが、主に共有ロックによって引き起こされるデッドロックの数が減るためです。
分割分析法は、また、排他的方法と言うことができます。ロジックの一部のみが実行され、例えば、上記のアプリケーションは、2つのステップに分割され、最初に保存し、その後、送信し、唯一のデッドロックの結果を保存します。
SQLの様々なロックとその互換性を説明し、唯一の共有ロックが互いに互換性があることを知っているようなロックのシナリオを知って、これらを理解することはすぐに純粋な読み取り操作がブロックされていないに反応することができます
トランザクションの分離レベルの違いはロックの動作に影響を与えますが、トランザクションの分離レベルを下げてもデッドロックがなくなるわけではないことに注意することが重要です。
ブロッキングはデッドロックにエスカレートするだけです。
この記事では、2つの方法を追跡し、デッドロックの原因の性質を分析する方法を説明するために、SQLを介してパフォーマンスモニターが付属しており、簡単にデッドロックに関連する情報をエクスポートすることができます。
デッドロックがどのように発生するのか、非常に詳しく説明されています。
デッドロックの記事から得られた重要な結論：
デッドロックのほとんどは最適化されていないクエリが原因なのですが、このプロジェクトではアプリケーションの処理にロジックが多すぎるため、短期間で効果的に最適化することができそうにないので、当面はおそらくあまり良くない解決策、つまり排他ロックの競合を減らす方法、簡単に言うと、何らかの手段でプログラム内のデータを更新したり挿入したりするロジックを同時に呼び出さないようにする方法を採用しました。どうすればいいのかわかりませんが、やってみようと思います。
オフビート・ソリューション
キューをキューイングチケットを介してデータの挿入だけでなく、更新の並行性を解決するために、原則は、スレッドがデータを挿入したい、最初のチケットとし、キューイングは、そのターンの数は、データベース操作を実行するときに、他のスレッドがキューイングを達成するためにロックの自己分類を介して、実行されています。デッドロックの問題にこの方法***手続き上の解決策が、そうすることをお勧めしません、この型破りな手段の理由だけでなく、既存のプログラムのロジックに従います。あなたはまた、EFのデッドロックの問題を解決している場合は、私とマネージャーを共有することができます。
public int AddWithSpinLock(ObjectModel.Request svarRequest)
{
bool lockTaken = false;
svarRequest.Ticket = Guid.NewGuid();
var newRequestId = 0;
try
{
_spinlock.Enter(ref lockTaken);
_queue.Enqueue(svarRequest);
while (null != _queue && _queue.Count > 0 && _queue.Peek().Ticket == svarRequest.Ticket)
{
// do something<br> _queue.Dequeue();
return newRequestId;
}
}
catch (Exception ex)
{
if (lockTaken) _spinlock.Exit(false);
_queue.Dequeue();
throw ex;
}
finally
{
if (lockTaken) _spinlock.Exit(false);
}
return newRequestId;
}
