0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【Data Base】busy状態が頻発したケーススタディ

Posted at

#事象
初めての新規開発案件で、自分の製造した機能でbusy状態のエラーログが頻発してしまった。

##原因
調査の結果、原因は他機能同士でデッドロックが発生してしまうことに起因していた。

##調査方法
悲観ロックをかける順序を洗い出した。
例)昇格機能:対象の社員を確認 → 所属する店長グループを確定 → 配属エリアの選定 → 配属店舗の選定
       t_staff → t_maneger_group → t_area → t_shop
  退職機能:所属店舗の確認 → 対象社員の上長を確認 → 対象社員の削除
       t_shop → t_manger_group → t_staff

(無理に例えると分かりにくい気もするけど、せっかく書いたし残します。)

##対策
テーブルをidなどで管理して、ロックする順序をプロジェクト全体で統一するのが一般的だよね~との事。

###最後に。
ある程度、デッドロックが原因であることは当たりがついていたが、それを起こしている機能がなかなか見つからずに困り果てていた。
やむを得ず先輩に助力を求めたところ、あっさりと原因の機能を見つけられたので調査方法の覚書として。

今回は、スケジュールがきつすぎてコーディング規約とかゆっるゆるで走り出してしまったせいで
これ以外にもたくさんの面倒くさいことが起こりました。
雁字搦めで作るのは鬱陶しいかもなとか思ってましたが、フリーダム過ぎると初歩的なミスが多発するということで非常に勉強になりました。

初投稿でよくわからないままにあげてしまいますが、最後まで読んで頂けたなら幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?