InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
transactionの途中でトランザクションが切れてしまった時にそのトランザクションを殺す方法 - Garbage in, gospel out
起こったこと transactionモードで作業途中、セッションが切れた。 そのとき特定tableにinsertをしたがcommitしていない状態だった。 後ほど再度そのtableをselectしたが、当然commitしていないのでデータがなかった。 しかしinsertしようとすると、 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction というエラーが表示され失敗した。 原因 transactionがロックを取得したまま放置状態になっていたために発生した。 対処 基本方針は show processlist; と show innodb status; の結果を見比べてそれっぽいthread見つけて kill [thread id] する。 show processlist; してみると、今回
LOCK IN SHARE MODE の使いドコロを間違えてデッドロック - ngyukiの日記
先日、作っていたシステムでデッドロックがわりかし頻繁に発生することが判りました。 RDBMS のデッドロックは必ずしもバグでは無く、無理に対応するよりアプリケーション側でハンドリングしてトランザクションのリトライなどを行った方がいい場合もあると思いますが、このケースでは明らかにバグでした。 デッドロックするクエリ テーブル定義は次の通りで・・・ CREATE TABLE tt ( id INTEGER NOT NULL PRIMARY KEY, no INTEGER NOT NULL ); INSERT INTO tt VALUES (1, 0); 次のようなSQLで更新します。 BEGIN; /* (1) */ SELECT @no := no FROM tt WHERE id = 1 LOCK IN SHARE MODE; /* (2) */ UPDATE tt SET no = @n
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
ElixirでSI開発入門 #2 Ectoで楽観的ロック - Qiita
（この記事は、「Elixir or Phoenix Advent Calendar 2017」の9日目です） fukuoka.exのメンバーにより連載されています。 昨日は、@piacere さんの「ExcelでElixirマスター2回目：「列の抽出」と「Web表示」でした 今日は、実際のプロダクト開発のお話２回目です。 はじめに Elixirで実際にプロダクト開発した経験からサンプルコードを交えて解説する本連載 基本となるデータベース排他制御の後編は、 Webサービスなどでより一般的な楽観的ロックです。 悲観的ロックと楽観的ロックに関する一般的な解説は例によってこちらの記事をお勧めします。 -> 排他制御（楽観ロック・悲観ロック）の基礎 本連載の前回記事はこちら |> ElixirでSI開発入門 #1 Ectoで悲観的ロック Ecto.Changeset.optimistic_lock(
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
Double-checked locking - Wikipedia
In software engineering, double-checked locking (also known as "double-checked locking optimization"[1]) is a software design pattern used to reduce the overhead of acquiring a lock by testing the locking criterion (the "lock hint") before acquiring the lock. Locking occurs only if the locking criterion check indicates that locking is required. The original form of the pattern, appearing in Patter
時刻印ロック - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "時刻印ロック" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2023年1月） 時刻印ロック（じこくいんろっく）とは、楽観的ロックの概念を用いたロック (情報工学)の手段の一種である。更新開始時点の対象データに記録されている最終更新時刻を記憶しておき、更新処理を行う際に再度対象データの最終更新時刻と比較する。もし異なっていたら、他によって内容が更新されてしまったと判断し、更新をあきらめ、同一であれば、対象データ更新とともに処理をした現在の更新時刻を記録する。 関連情報[編集] 楽観的並行性制御
楽観的並行性制御 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "楽観的並行性制御" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2023年1月） 楽観的並行性制御（らっかんてきへいこうせいせいぎょ、optimistic concurrency control）とは、並行性制御(ロック)の手段の種別の一種である。楽観的ロックの概念である。他の処理と競合してはならないトランザクションにおいて、開始時には特に排他処理など行なわず、完了する際に他からの更新がされたか否かを確認し、もし他から更新されてしまっていたら自らの更新処理を破棄し、エラーとする。対照的に悲観的並行性制御がある。 関連項目[編集] 時刻印
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
デッドロック - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "デッドロック" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2021年9月） デッドロックの例： 両方のプロセスが実行を継続するためのリソースを必要としている。 P1は追加のリソースR1を必要とし、リソースR2を保持している。 P2は追加のリソースR2を必要とし、リソースR1を保持している。 4つのプロセス（青線）が1つのリソース（中央の円）を要求する。プロセスは左側より右側を優先するというポリシーに従う。すべてのプロセスが同時にリソースをロックすると、デッドロックが発生する。これは対称性を崩すことで解決される。 デッドロック (英:
スピンロック - Wikipedia
この項目では、計算機科学におけるスピンロックについて説明しています。核磁気共鳴におけるスピンロックについては「交差分極」をご覧ください。 スピンロック（英: spin lock, spinlock）[1]とは、計算機科学におけるロックの一種で、スレッドがロックを獲得できるまで単純にループ（スピン）して定期的にロックをチェックしながら待つ方式。スレッドはその間有益な仕事を何もせずに動作し続けるため、これは一種のビジーウェイト状態を発生させる。獲得されたスピンロックは明示的に解放するまでそのまま確保されるが、実装によってはスレッドがブロック（スリープ）したときに自動的に解放される場合もある。 スレッドが短時間だけブロックされるならば、スピンロックは効率的であり[2]、オペレーティングシステムのプロセススケジューリングのオーバーヘッドを防ぐことにもなる。このため、スピンロックはカーネル内でよく使
ActiveRecordで行ロックをかける方法
行ロックとは 行ロックとは、テーブルの同一レコードに対して、複数同時に更新できないように制限する仕組みのことです。 Ruby on RailsのActiveRecordには２種類のロック方法があります。 楽観的ロック（Rails依存） 悲観的ロック（DBMS依存） それぞれの違いや使い方について解説していきたいと思います。 楽観的ロック 楽観的ロックとは、DBMSの機能に頼らずロックバージョンをレコードに保存しておくことで、取得時と変更時にロックバージョンに変更がないか確認し、変更があった場合は例外を発生させる方法です。 ロックするタイミング データ更新時 データを複数同時に取得することができるが、途中で更新されていた場合は、更新できない 仕組み テーブルにlock_versionフィールドを追加する lock_versionが書き換わっていたらActiveRecord::StaleObj
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deadlock - Wikipedia
ロック待ちのタイムアウト時間の確認／設定 - Qiita
MySQL :: MySQL 8.0 Reference Manual :: 17.7.2.4 Locking Reads
Advisory Locks and How to Use Them
Mutex sleep is taking a lot of CPU
ログイン - はてな
