前回の続き
今回はトランザクションのはなしです。
ちなみに今回は100%読み物です。
トランザクション
例えば、銀行の預金を管理するデータベースがあったとします。
Aさんは10万円の預金があります。
また、キャッシュカードはAさんと、Aさんの奥さんのBさんも家族カードとして同一口座のものをもっています。
例えば、ほぼ同時に2人が6万円ずつ払い戻しをしたとします。
ほぼ同時だったので、データベースを参照したら10万円の預金があったので、結果6万円ずつ払い戻しができました・・・。となったら大変なことですよね。
こんな時に必要な処理がトランザクションです。
トランザクションは複数の処理をひとまとめにして、処理の最中は他の処理によってテーブルが更新されないようにロックしてしまうものです。
今回の預金の話は、
- 預金額を参照する
- 払い戻し金額が預金額を超えていたら、処理を終える。
- 払い戻し金額が預金額を超えていなければ払い戻し金額を書き込み、現金を出力する。
という処理ですね。(実際はもっとあると思いますが、ひとまず単純に考えます)
トランザクションによるテーブルロックがなければ、預金額を参照してAさん、Bさんともに10万円というデータが得られてしまえば、2人とも上記の3の処理を行ってしまうということになってしまうのです。
ですから、上記1，2，3の処理を一連のひとつの処理と考え、先にアクセスした人がテーブルロックを行い、次にアクセスした人は前の人のロックが解除するのをまっているというのがトランザクションの考え方です。
コミットとロールバック
トランザクションは複数の処理をひとつにまとめるわけですから、処理途中にひとつひとつが確定したのでは、まとめるとはいえません。
そこで、仮にデータの書き換えなどの処理を行い、最終的にそれで確定するか、もしくは処理をなかったことにするかを選択できます。
もし、処理を確定するときはコミット、処理をなかったことにするときはロールバックを行います。
また、ロールバック処理を行う際は、例外がおきたとき、つまりエラー検知を行うことがセットにされることが多いので、これも紹介をしておきます。
エラー検知
処理を大量に行うとき、必ずしもすべてうまくいくとはかぎりません。
ですので予期せぬ例外がおきたときの対応をしておくことも必要です。
エラーが起きたときにはどのように処理を行うのかを決めておく必要があります。
エラーが予期できるようなことであれば、ルールベースで回避しておくべきでしょうが、そうでないときは多くは、トランザクション内でおきていることであればロールバックさせておくことが無難です。
以上、今回はここまで。
次回は実践してみたいと思います。
