Rails におけるレースコンディションの例とその回避方法 - LukeSilvia’s diary

最近立て続けにレースコンディション問題に遭遇したのでメモ。 レースコンディション(競合状態)とは、複数のプロセスやスレッドが共有リソースに対して何らかの操作をする際に、処理のタイミングによって結果が異なってしまう状態のこと。よくトランザクションの解説の際に銀行口座の例として紹介されるおなじみのやつです。 今回は、アプリケーションの書き方によって発生するレースコンディションと、MySQL のテーブル定義時の制約不足で発生するレースコンディションについてそれぞれ紹介したいと思います。 どちらの場合も共有リソースはDB で、条件を満たすと意図しない形でデータが保存されてしまいます。 サンプルアプリケーション サンプルアプリケーションとして、簡単なアクセス解析機能付きの短縮URL ツールを考えます。 アクセス解析機能として、以下のような機能を持つとしましょう。 URL毎 にクリック数を計測できる

[suginoy]

これはRailsエンジニアみんな読むべき

[hory-gom]

“この問題に対応するにはDB 側でインクリメント処理を行う必要がありますつまり、アプリケーションはDB に対して「インクリメントして!」という命令のみを発行します。”

[bluerabbit]

ActiveRecord::Base.increment_counter

[skyriser]

トランザクションの分離レベルの色々とかも。よくまとまってます。すばらしい。

[willnet]

ActiveRecord::Base.increment_counterを使うと、カウンタ値のロストアップデートを回避できる

[aquarla]

昨日つぶやいたAR::Base#findのlockオプションやら、トランザクション分離レベルやら select for updateの話が載ってる

[Clock0311]

increment_counter っていうのがあるのか。知らなかった。

[ogijun]

あとで書く、書けたらいいなあ

[kakuhen1rfeverheiten]

インクリメント increment

[kamipo]

ActiveRecord::Base.increment_counter

[lizy]

これはISOLATION LEVELの問題じゃないですか？1個目はREPEATABLE READがあれば大丈夫か。2個目はSERIALIZABLEが必要かな

[IwamotoTakashi]

アトミックな処理を使え、アトミックにできないなら制約で工夫しろ、という話

[sgtakeru]

気をつけないと。