こんにちは、上の画像のデッドロック グラフの部分をご覧ください。同じテーブルを更新する 2 つのトランザクションがあり、そのうちの 1 つはそのテーブル (同じ行) を 5 回更新する長いトランザクションですが、もう 1 つのトランザクションはそのテーブルを 1 回だけ更新し、小規模です。 2 つの DB ヒットのトランザクション。デッドロック グラフから、両方のトランザクションが異なる行に X ロックを持ち、U ロックを取得しようとしていることが論理的に正しい。短いトランザクションが更新クエリをまだ起動していないのに X ロックを取得する理由がわかりません (デッドロックを引き起こすのは更新クエリであるため、まだ起動されていないことを意味します)。どんな助けも非常に重要です。1) 分離レベル read commit を使用しています 2) 2 番目/1 番目のトランザクションが X ロックを取得する方法を理解できませんが、他のトランザクションはすでにいくつかの行で X ロックを取得しています。
他のトランザクションがすでにいくつかの行でXロックを取得している間に、2番目/最初のトランザクションがXロックを取得する方法を理解できません。
これは、データベースとそのパフォーマンスの背後にある魔法です。ロックはさまざまなレベルで発行でき、2 番目のトランザクションがテーブル スキャンを使用しなかった場合、最初のトランザクションと競合することなく X ロックを発行できます。インデックスおよびテーブル スキャンを使用して検索されたレコードの更新が行われなかった可能性があるため、テーブルに複数の同時 X ロックが存在する可能性があります。
Updateクエリでは、最初にUロックが適用され、次にその特定の更新された行のXロックにアップグレードされることを読みました。
いいえ。更新では、レコードの X ロックを直接使用する必要があります。U ロックは、更新するデータを読み取る読み取りクエリによって強制する必要があります (これは、@Marc がコメントで言及したことです)。ご存知のように、EF はヒントを使用できないため、これをサポートしていません。