令和4年午後1問3 設3 空欄う~か

Fさん  
(No.1)
表3のケース2で棚別在庫の更新によるデッドロックが起きるリスクは無いという事が分かってる。
→注文番号毎にバッチを分割実行しても、全てのバッチが棚番号と商品コードの順に棚別在庫を更新する為。

上記前提で、以下の場合にデッドロックが発生する理由が分かりません。
ピッカーAが1番目に棚3番から商品S3、2番目に棚6番から商品S6を出庫する
ピッカーBが1番目に棚6番から商品S6、2番目に棚3番から商品S3を出庫する

ピッカーがどの順番でどの棚からどの商品を取ろうと、主キー順にバッチが実行されるのんであればデッドロックは発生しない認識です。
もし出庫番号と出庫時刻順に読み込むというのであれば、デッドロックが発生するというのも分かりますが。

的外れな思い込みをしているかもしれませんがご回答いただけると幸いです。
2023.07.23 01:59
Fさん  
(No.2)
この投稿は投稿者により削除されました。(2023.07.23 03:11)
2023.07.23 03:11
logres_fanさん 
DB ブロンズマイスター
(No.3)
ピッカーの順路が1方向となる出庫指示を“出庫指示”に登録する
“出庫指示”を主キー順に読み込み、その順で“棚別在庫”を更新し
  
  主キー順、つまり、ピッカーの順路が1方向となる順という設定がある。そして、明示されていないが、『周回せずに』という事なんだと思う。
  とある事情で追い越し・2週目の検討が行われると、前提条件が崩れて逆順混合になるのでデッドロック対策が必要になるのかと。
  設問3(2)の模範解答は、解読レベルが足りず、上手く解説出来ない。設定2(2)に準じているのであろうが、業界人なら阿吽の呼吸で盛り上がるのか?端折り過ぎ、回りくどいと思うのだが。
2023.07.24 16:53

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの書込みはできません。

その他のスレッド


Pagetop