Rails4で楽観的ロックを実装する - Rails Webook
ActiveRecordでは、lock_versionというカラムを追加するだけで楽観的ロックを利用できます。 レコード単位でlock_versionを保持しているため、レコード単位での更新が競合した場合、ActiveRecord::StaleObjectError例外が発生します。 動作確認 Rails 4.1 ActiveRecord 4.1 目次 楽観的ロックとは 楽観的ロック（ロックバージョン）の実装 楽観的ロックの使い方 楽観的ロックを画面から扱う 1. 楽観的ロックとは楽観的ロックとは、基本的には変更が競合しないだろうという状況に向いたロック手法です。 テーブルにロックバージョンカラムを持たせ、レコードを変更するたびにロックバージョンを更新し、更新しようとしたときにロックバージョンが異なっている場合には、更新の競合が発生したと判断しレコードを更新しないようにします。 Activ
トランザクションを強制的に終了させる - HHeLiBeXの日記 正道編
前置き MySQL 5.1で、InnoDBなデータベースを使って何かを開発している最中には、トランザクションがコミット(またはロールバック)される前にプログラム側の処理が(Fatal errorなどで)異常終了したりして、トランザクションがロックを取得したまま放置状態になってしまうことがよくあるらしい(謎)。 そんな時、MySQLのコマンドラインから更新クエリを発行すると、しばらく後に次のようなエラーが返ってくることがある。 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 一応参考までに書いておくと、このエラーが返ってくるまでの時間は、次のコマンドで知ることができる。 mysql> show global variables like 'innodb_lock_wait_timeout';
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
MySQL - ネクストキーロックってどこまでロックされんの？ - Qiita
個人的にMySQL一番の鬼門のネクストキーロック。未だにまともな正解はわからないけれど、法則性らしきものが理解できてきたのでまとめてみる。 そもそもネクストキーロックとは InnoDBの行ロックはネクストキーロックを採用している。検索時はネクストキーロックを用いてインデックス走査を行うので、ギャップロックが起こる場合は常に先のギャップもロックされており、これによってファントムリードを防ぐ。一意のインデックスを持つ固有値検索の場合はギャップロックする必要がないが、値域検索の場合はギャップロックをする。 固有値検索はギャップロックしないはずだが、存在しない行を読み取ろうとした場合は排他・共有ロックではなく、ギャップロックがかかる。同時にネクストキーロックもかかるのでproduct_id = 19にはINSERTできない。 mysql> select * from products where
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
SELECT FOR UPDATEする上での注意点 - blog.nekokak.org
MySQLで行ロックかけてトランザクションを効かせたい場合、SELECT FOR UPDATEを使うわけですが、 以下のようなクエリを発行しちゃうと行ロックではなくテーブルロック風味に扱われるので注意。 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from user order by id DESC limit 1 for update; +----+---------+ | id | name | +----+---------+ | 4 | xaicron | +----+---------+ 1 row in set (0.00 sec)このクエリを実行中に別のセッションから同じことを実行するとロック待ち状態になり 最悪デッドロックで死亡します。 ERROR 1205 (HY000): Lock
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 9.8.4 InnoDB レコード、ギャップ、およびネクストキーロック
レコードロック: これはインデックスレコードのロックです。 ギャップロック: これはインデックスレコード間にあるギャップのロック、先頭のインデックスレコードの前や末尾のインデックスレコードのあとにあるギャップのロック、のいずれかです。 ネクストキーロック: これはインデックスレコードに対するレコードロックと、そのインデックスレコードの前にあるギャップに対するギャップロックとを組み合わせたものです。 レコードロックでは、テーブルにインデックスが定義されていなくても必ず、インデックスレコードがロックされます。そのような場合には InnoDB によって隠しクラスタインデックスが作成され、このインデックスを使ってレコードロックが行われます。項9.10.1. 「クラスタインデックスと二次インデックス」 を参照してください。 デフォルトでは、InnoDB は REPEATABLE READ トランザク
tree-tips: MySQLのlock in share mode | MySQL
lock in share modeとは？ lock in share modeは、共有ロック・shared lock・slock、と言われているロックです。 for updateは、排他ロック・xlock、と言われています。 参照(select)する時にロックをする機能です。 lock in share modeはどんな時に使う？ 主な使い道は、ファジーリード・ロストアップデートを防ぐ、です。 ファジーリードはトランザクション分離レベルがread committed以下の場合の発生します。repeatable readの場合はそもそもANSI/ISO SQLの仕様上発生しません。 具体的な使い所としては、一覧画面の表示時のSQLや、不正データ検出、等で使うかと思います。 for updateとの違いは？ 最大の違いはslockによる参照をブロックしない・されない点です。つまり、参照同士の
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.4 読取りのロック
データのクエリーを実行してから、同じトランザクション内で関連データを挿入または更新する場合は、通常の SELECT ステートメントで十分な保護が提供されません。 ほかのトランザクションは、クエリーが実行されたばかりの同じ行を更新または削除できます。 InnoDB では、追加の安全性が提供される 2 つのタイプのロック読み取りがサポートされています。 SELECT ... FOR SHARE 読み取られる行に共有モードロックを設定します。 ほかのセッションもその行を読み取ることができますが、トランザクションがコミットするまで変更することはできません。 これらの行のいずれかがコミットされていない別のトランザクションによって変更された場合、クエリーはそのトランザクションが終了するまで待機してから、最新の値を使用します。 SELECT ... FOR SHARE は SELECT ... LOCK
ePhotoChest: お宝写真をパスワードで隠せる、男のロマン無料アプリ。471 | AppBank
これや！entrypostmanはこういうアプリを探してたんや！！！ ePhotoChest は出来れば隠しておきたい画像を隠しておける無料アプリ。 要するに、パスワードでロックできる画像ビューアーです。 知り合いに「iPhoneに求めることは『エロ』をどこにでも持ち歩けること！」と言い放ったテレビ局マンがいました。そう、このアプリは彼のような人に必要なアプリィィィ！！！ ePhotoChestの紹介はこちらから 誰にでも、秘密にしておきたいことがあります。 エロ本をどうどうと机の上においておく、と言うような少年時代を過ごした男性は世の中に1％もいないでしょう。大半の男性は隠しているはず。 最近は女子まで、腐女子という名の下好き勝手やってます。 そんなあなたにこのアプリ紹介を送ります。 これが起動画面。パスワードを要求されます。 初回起動時のパスワードは空欄で設定されています。 まずログイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
