Rails におけるレースコンディションの例とその回避方法 - LukeSilvia’s diary
最近立て続けにレースコンディション問題に遭遇したのでメモ。 レースコンディション(競合状態)とは、複数のプロセスやスレッドが共有リソースに対して何らかの操作をする際に、処理のタイミングによって結果が異なってしまう状態のこと。よくトランザクションの解説の際に銀行口座の例として紹介されるおなじみのやつです。 今回は、アプリケーションの書き方によって発生するレースコンディションと、MySQL のテーブル定義時の制約不足で発生するレースコンディションについてそれぞれ紹介したいと思います。 どちらの場合も共有リソースはDB で、条件を満たすと意図しない形でデータが保存されてしまいます。 サンプルアプリケーション サンプルアプリケーションとして、簡単なアクセス解析機能付きの短縮URL ツールを考えます。 アクセス解析機能として、以下のような機能を持つとしましょう。 URL毎 にクリック数を計測できる
update_attribute とupdate_attribtues の違い - LukeSilvia’s diary
以前に書いたコードを読んでいると、1カラムの値だけを変えるからといって、update_attribute メソッドを使っている部分があった。これはあまりよくない update_attribute とupdate_attribtues の違い 前者は1つのカラムの値を、後者は複数のカラムの値を更新できる。という違い以上に、「update_attribute メソッドはvalidation なしに更新、update_attributes メソッドはvalidation ありで更新」という違いがあります。 つまり、update_attribute 使うと、検証処理なしに、値が更新されてしまう。ソースを見ると、update_attribute の方は、save(false) を使って更新しているのが分かる。 activerecord/lib/active_record/base.rb at mas
find_by_sql を使う際のTips - LukeSilvia’s diary
読んでいたコードで面白いテクニックを使っていたのでメモ。 Rails のActiveRecord のfind 系メソッドは優秀だと思うけど、自分でSQL を書きたい時があると思います。そこで、find_by_sql を使うわけですが、その際、大規模なSQL を書く場合のTips です。 環境 ruby 1.8.7 rails 2.2.2 パラメータによってSQL 自体を変えたい場合 例えば、SQL が以下だったとします。 RDBMS はSQLite3 SELECT * from users where name = xxx; これを扱う、find_by_sql が以下のような感じ。 User.find_by_sql(["select * from users where name = :name", {:name => 'bob'}]) #=> [#<User id: 1, name: "
MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
