残高転送のトランザクション風処理

引いたところで落ちると、お金が消える

A の口座から 300 円引いて、B の口座に 300 円足す。送金の処理は、書いてしまえば 2 行です。

この 2 行の間でプロセスが落ちると、A だけが 300 円減った世界が残ります。合わせて 1500 円あったはずのお金が 1200 円になっています。誰も受け取っていない 300 円が、どこにも無い状態です。

バグではありません。2 行とも書き方は正しく、順番も正しい。それでも壊れます。「片方だけ実行された状態」が存在しうる限り、いつか必ず起きます。

だから複数の書き換えは、全部やるか 1 つもやらないかのどちらかに固定します。これがトランザクションの原子性（Atomicity）です。データベースの ACID という 4 文字はこの A から始まり、残る 3 つは一貫性、分離性、永続性ですが、送金でまず効くのは A です。

途中まで書き換えない書き方にする

止まっても壊れないようにする道は 2 つあります。書き換える前の状態を控えておいて失敗したら戻すか、書き換えてよいと分かるまで 1 か所も触らないかです。自分の手で書くなら後者が確実です。

送金してよいかどうかは、引く前に判定できます。残高が足りるかは残高を見れば分かる。分かった時点で分岐して、足りなければ何も触らずに返してしまえば、「引いたのに足せなかった」状態が生まれる余地そのものが消えます。

解説

現場の話 — 本物のデータベースは前者を選んでいます。変更を本体に反映する前に別のログへ書き出しておき、途中で電源が落ちても再起動時にログから復元します。COMMIT が一瞬で終わるように見えて裏で泥臭い仕事をしているのは、この控えを取っているからです。

渡された辞書を書き換えると、呼び出し元まで変わる

もう 1 つ、原子性を静かに壊すものがあります。引数で受け取った辞書を、そのまま書き換えることです。

返り値を受け取ってもいないのに、元の scores まで変わっています。辞書やオブジェクトは中身そのものが渡されるので、受け取った側の書き換えが呼び出し元に筒抜けになります。

これが混ざると、途中まで書き換えてから「やっぱりやめます」と元の値を返しても、呼び出し元の辞書はもう汚れています。先にコピーを作り、コピーだけを触って返してください。

dict() やスプレッドで作れるのは 1 段だけのコピーです。今回の口座のように値が数値なら、これで足ります。

やってみよう

transfer(accounts, sender, receiver, amount) を完成させてください。

1. accounts はコピーしてから触る。渡された辞書そのものは最後まで変えない
2. sender の残高が amount に足りなければ、引きも足しもせずに返す
3. 足りるときだけ、sender から引いて receiver に足す

テストの期待値を見ると、送金が成功した場合も失敗した場合も、全口座の合計は入力と同じままです。引く処理と足す処理のどちらか一方だけが走ると、この合計が合わなくなります。

1. sender の残高が amount 未満なら何も変更せず返す（rollback 相当）
2. 送金成功時は sender から amount を引き、receiver に amount を足す
3. 入力 accounts を直接書き換えず、新しい辞書 / オブジェクトを返す