skillup

技術ブログ

プログラミング全般

トランザクション、ロールバックに関する考察

投稿日:

今までトランザクションの単位は基本的に処理の開始から終了までを範囲にすることが多かったのですが(ループがある場合はループ全体ではなく、1ループをトランザクションとみなします)、複数の処理が絡む場合、不都合が起きることがあります。

個人的にトランザクションを分けるときなどでポイントとなる点を。

失敗した場合に本当に最初からロールバックすべきか?

要は失敗した場合に、「失敗した処理」として明記するような場合、その処理自体はコミットする必要があります。

ではなく、

のようにする必要があります。

要は処理1と処理2は連続しているけれどもコミットの単位としては分割したいときなどですね。

仕様やそもそもユーザーがどのように使うかという問題になってきます。

処理1は完結しているので、次は処理2からはじめたい時(始めるのが可能な時)は処理を分ける必要があります。

あるいは単純に1処理が長すぎる場合なども適切に分けたほうが良いでしょう。

成否が確認できない、または影響が少ない

例えば完了した後、メールやプッシュ通知などを送ったことの成否の確認をしてコミットするか否かですが、そもそもこれらのサービスの成否というのは完全にはわかりません。(送信成功と出たところでユーザーに完全にメールや通知が届くかは保証できない)

そのため、コミットの外におく必要がある場合もあるでしょう。

またはこけたとしてもロールバックまでには値しない処理(ログ的なデータの書き込みなど)はトランザクションの範囲外にしたり、処理結果によるロールバックを行わないということもあるでしょう。(前回のエラーのブログのExceptionを握りつぶす時に似てます。)

ロールバックできない処理の考慮があるか

またトランザクション内では処理順番なども大切です。

例えばAPIでの登録→DBの登録とすると、DBでこけた場合、APIの処理の取り消ししなければいけなくなります(API側に取り消しする機能がない場合、宙ぶらりんのデータができてしまいます。)。

そのため、このようなロールバックが難しい処理の場合は、DBの登録→API更新などとすると処理が確定させるかどうかをAPI更新の成否で判断することができるため、APIがこけたときにDB側のロールバックをすることができます。このため整合性のあるデータ登録をすることができます。

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

短いコードを書く

私が普段コードを書くときに考えていることは常にいかに短くかけるか、ということといかにバグを生み出さないかということです。 基本的にはできるだけ、短くシンプルに書くようにしています。 そうすることであと …

no image

テスト環境のデータ作りに関して

単体テスト以降の環境ですとテストのデータを作ることがなかなか大変だと思います。マスタなどはそのままもらうこともあると思いますので、主にトランザクションデータについて。 以前もこのネタに関しては色々書い …

no image

コメントについて

リーダブルコード 第5・6章はコメントについて。 今回はコメントです。ここは結構賛否両論になるところではないかと思います。 ざっくり分けると「できるだけコメントは詳しく書くこと」という意見と「コメント …

no image

テストのダミーデータ作成

データベースに大量のデータを作りたいときにいつもあああやhoge,aaaですとデータという感じがしないですし、抽出や集計ができません。 なるべく自然に近いデータが欲しいのですが、簡単に作れる方法があり …

no image

アクセストークンの分類について

認可情報を取得する際に、ID &パスワードではなく、アクセストークンで認証を行うサービスは多いと思うのですが、アクセストークンにも色々ありますので、再度まとめておこうと思います。 以前まとめた …

アーカイブ