HOME»データベーススペシャリスト掲示板»デッドロックに関して
投稿する
デッドロックに関して [0134]
wakaさん(No.1)
デッドロックの原因とされる「逆順に処理が実行される」というのがイメージできません。
トランザクション1がテーブルA→テーブルBの順で更新を行い、
トランザクション2がテーブルB→テーブルAの順で更新を行うときは、逆順になっているというのが理解できます。
同じ処理内容の複数のトランザクションが同じテーブルの同じ行に対して処理するときに逆順になることがあるのでしょうか?(H17 午後1 問4の問題)
また。アクセスする順序を定義してトランザクションがその順番通りに処理をすることで回避できるということですが、仮に商品番号順に処理をしても、同じ商品番号を更新するトランザクションが複数あったらデッドロックが発生するのではないでしょうか?
よろしくお願いいたします。
トランザクション1がテーブルA→テーブルBの順で更新を行い、
トランザクション2がテーブルB→テーブルAの順で更新を行うときは、逆順になっているというのが理解できます。
同じ処理内容の複数のトランザクションが同じテーブルの同じ行に対して処理するときに逆順になることがあるのでしょうか?(H17 午後1 問4の問題)
また。アクセスする順序を定義してトランザクションがその順番通りに処理をすることで回避できるということですが、仮に商品番号順に処理をしても、同じ商品番号を更新するトランザクションが複数あったらデッドロックが発生するのではないでしょうか?
よろしくお願いいたします。
2020.09.17 08:57
mkkさん(No.2)
該当の問題をやってないので本文から想像しつつですが...
ネットショッピングとかでカートにモノを突っ込んだ状態のような
何らかの注文処理の明細データをイメージしてください(S01~S04は商品番号)
Aさんの注文 Bさんの注文
------------------------------------
S01 5個 S04 3個
S03 10個 S02 6個
S04 15個 S03 9個
在庫テーブル(☆更新対象☆)
------------------------------------
S01 1000個
S02 1000個
S03 1000個
S04 1000個
注文を確定したら在庫テーブルから在庫数が減っていくとします。
仮にAさんとBさんがほぼ同時に注文を確定したとして
1.注文データが上から順に処理される場合(カートに突っ込んだ順とか)
Aさんの注文 Bさんの注文
------------------------------------
S01 5個(更新) S04 3個(更新)
↓ ↓
S03 10個(更新) S02 6個(更新)
↓ ↓
S04 15個(Bさん待ち) S03 9個(Aさん待ち) <デッドロック
2.商品番号順に処理される場合
Aさんの注文 Bさんの注文
------------------------------------
S01 5個(更新) S02 3個(更新)
↓ ↓
S03 10個(更新) S03 6個(Aさん待ち)
↓ ↓
S04 15個(更新) ↓
↓ ↓
コミット ↓
S03 6個(更新)
↓
S04 9個(更新)
↓
コミット
商品番号を気にせず上から順に更新される場合だと
Aさんが処理しようとした商品は既にBさんの処理で更新されていて
Bさんが処理しようとした商品は既にAさんの処理で更新されてしまっており
デッドロックが起きてしまいます。
一方で商品番号順にすることで
在庫テーブルへの更新順が入れ替わることがなくなりデッドロックが起きません。
(※商品番号順なので、S04の処理が終わった後に、Bさんの注文で
処理したS02の商品が更新対象として回ってくることがない)
上記例ではAさんの方が若干早かったとして書いてますが
Bさんの方が早かった場合でも同様ですし、同時に処理されるユーザーが
他に複数発生しても在庫テーブルでデッドロックがかかることはありません。
ネットショッピングとかでカートにモノを突っ込んだ状態のような
何らかの注文処理の明細データをイメージしてください(S01~S04は商品番号)
Aさんの注文 Bさんの注文
------------------------------------
S01 5個 S04 3個
S03 10個 S02 6個
S04 15個 S03 9個
在庫テーブル(☆更新対象☆)
------------------------------------
S01 1000個
S02 1000個
S03 1000個
S04 1000個
注文を確定したら在庫テーブルから在庫数が減っていくとします。
仮にAさんとBさんがほぼ同時に注文を確定したとして
1.注文データが上から順に処理される場合(カートに突っ込んだ順とか)
Aさんの注文 Bさんの注文
------------------------------------
S01 5個(更新) S04 3個(更新)
↓ ↓
S03 10個(更新) S02 6個(更新)
↓ ↓
S04 15個(Bさん待ち) S03 9個(Aさん待ち) <デッドロック
2.商品番号順に処理される場合
Aさんの注文 Bさんの注文
------------------------------------
S01 5個(更新) S02 3個(更新)
↓ ↓
S03 10個(更新) S03 6個(Aさん待ち)
↓ ↓
S04 15個(更新) ↓
↓ ↓
コミット ↓
S03 6個(更新)
↓
S04 9個(更新)
↓
コミット
商品番号を気にせず上から順に更新される場合だと
Aさんが処理しようとした商品は既にBさんの処理で更新されていて
Bさんが処理しようとした商品は既にAさんの処理で更新されてしまっており
デッドロックが起きてしまいます。
一方で商品番号順にすることで
在庫テーブルへの更新順が入れ替わることがなくなりデッドロックが起きません。
(※商品番号順なので、S04の処理が終わった後に、Bさんの注文で
処理したS02の商品が更新対象として回ってくることがない)
上記例ではAさんの方が若干早かったとして書いてますが
Bさんの方が早かった場合でも同様ですし、同時に処理されるユーザーが
他に複数発生しても在庫テーブルでデッドロックがかかることはありません。
2020.09.20 22:02
mkkさん(No.3)
あれーーー
プレビューで何度も確認したのに矢印がズレてしまった
なんてことかしら
プレビューで何度も確認したのに矢印がズレてしまった
なんてことかしら
2020.09.20 22:03
wakaさん(No.4)
トランザクションの中の処理で参照される商品番号が逆順になるということなんですよね。
処理の順番が逆になるとずっと勘違いしていました。
商品番号順にロックすることで、別のトランザクションは解放待ちになり、デッドロックを回避できるのも納得することができました。
mkkさんありがとうございます。
処理の順番が逆になるとずっと勘違いしていました。
商品番号順にロックすることで、別のトランザクションは解放待ちになり、デッドロックを回避できるのも納得することができました。
mkkさんありがとうございます。
2020.09.21 09:14