デッドロックが起きたらどうなりますか。
DB が検知して片方を強制終了し、アプリには例外が飛びます。DB::transaction の第2引数でリトライ回数を指定できますが、根本対策は更新順序を揃えて発生自体を減らすことです。
面接官が見ているのは例外処理とリトライまで考えているか。
これは「トランザクションを張る範囲として妥当なのはどれですか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- DB が片方を強制終了して例外が飛ぶ。第2引数でリトライ回数を指定できる
その通りです。根本対策は、複数テーブルの更新順序をコード全体で揃えることです。順序がバラバラだと必ず起きます。 - 両方のトランザクションが自動的に成功する
デッドロックは両立できない状態なので、片方は必ず犠牲になります。 - アプリが停止するまで待ち続ける
DB がタイムアウトで検知して打ち切ります。 - データが壊れる
壊れません。ロールバックされるので整合性は保たれます。
面接官は何を見ているか
- DB側で片方が強制終了され、例外になると説明できた
- DB::transaction() の第2引数でリトライ回数を指定できると知っていた
- 発生を減らす方法（更新順序を揃える等）に触れた
模範解答
DB が検知して片方のトランザクションを強制終了し、アプリには例外が飛びます。DB::transaction($closure, 3) のように第2引数でリトライ回数を指定でき、デッドロック時は自動で再試行されます。ただし根本対策は発生を減らすことで、複数テーブルを更新する順序をコード全体で揃えるのが基本です。順序がバラバラだと必ず起きます。