MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） - 主に言語とシステム開発に関して
データベースには，「トランザクション分離レベル」というものがある。 以下では，それが なぜ必要なのか？ デフォルトのレベルでは，どうして駄目なのか？ PostgreSQLでは，どうやってレベルを変更・確認するのか？ などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは： 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか，のレベル。 ANSI規格では，４つのレベルがある。 READ UNCOMMITTED （一番低い） READ COMMITTED REPEATABLE READ SERIALIZABLE（一番高い） 徹底比較!! PostgreSQL vs MySQL 第３回：トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
