Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
lock in depth #TechLunch
Search
Livesense Inc.
PRO
April 23, 2014
Technology
100
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
lock in depth #TechLunch
2012/04/04(水) @ Livesense TechLunch
発表者:桂 大介
Livesense Inc.
PRO
April 23, 2014
More Decks by Livesense Inc.
See All by Livesense Inc.
味覇で作るパスタが美味い - 20261001_yabaubuki.dev
livesense
PRO
0
130
Rubyはただの⾔語に⾮ず
livesense
PRO
0
580
28新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
130
27新卒_総合職採用_会社説明資料
livesense
PRO
0
7.5k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
600
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
1
1.8k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
730
26新卒_総合職採用_会社説明資料
livesense
PRO
0
13k
Other Decks in Technology
See All in Technology
1つのリクエストを追って理解する - llm-dのP/D分離
akhino
1
160
⾮構造化データを価値に変える AI エージェント基盤とその組織
ivry_presentationmaterials
0
190
遠藤な_めぐろLT #38 「社内のAI活用推進」@麻布台_20261009
endonanana
0
130
V8のArray.prototype.flatを最大約20倍速くするまでと、巨大OSSへの大規模コミットの道のり
riyaamemiya
0
290
ストレスなくAIと付き合いたい!こんなときどうしてる?
namiki64
3
500
子育てエンジニアの可処分時間が減っても成長を諦めない戦い方
sudoakiy
6
4.6k
20261017福岡devIO 「AIは"良いダッシュボード"を作れるか?
jtakeda
0
140
AIにシークレットを見せない、WSL2で安全な開発環境
yazm
0
300
大型犬好きによるPugの紹介
yamanoku
1
160
AI × アーキテクト 第1・2章|生成AIの課題とアーキテクトの素養
daidaidai
0
170
スキマバイトという雇用形態は存在しないので、雇用期間1日のアルバイト契約を事業者とワーカーが結ぶ手続きを支えるのがタイミーなんです
akitoshiga
0
200
ソフトウェア ファクトリー - 再現性のあるソフトウェアの工場づくり / Software factory
iktakahiro
6
4.9k
Featured
See All Featured
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
300
For a Future-Friendly Web
brad_frost
184
10k
Test your architecture with Archunit
thirion
2
2.4k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.3k
Mind Mapping
helmedeiros
1
400
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
750
The Spectacular Lies of Maps
axbom
PRO
1
1.1k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
120
120k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Large-scale JavaScript Application Architecture
addyosmani
516
110k
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
Design in an AI World
tapps
1
350
Transcript
lock in depth
[email protected]
ACID • Atomicity トランザクションが「全て実行される」か「全く実行さ れない」ことを保証する • Consistency 整合性制約を満たす • Isolation
トランザクション中の過程が他から隠蔽される • Durability トランザクションが完了したら結果は永続する
• Exclusive lock and Shared lock • Read lock and
Write lock • Two-Phase Locking • Optimistic lock and Pessimistic lock • Timestamp Lock • Table-level lock and Row-level lock • Multiple granularity locking • Intention lock • Next key lock • Gap lock Lock
eXclusive and Shared lock • 排他/専有(X)ロックと共有(S)ロック • 共有ロック中は共有ロックのみ取得可 • 排他ロック中はどちらのロックも取得不可
• 共有ロック=読み込みロック • 排他ロック=書き込みロック
Two-phase locking(2PL) • ロックの取得と開放は2つのフェイズに分かれて いる • 取得の順番が違うとデッドロックが起こる • Expanding phase(Growing
phase) ロックが取得されていくフェイズ • Shrinking phase ロックが開放されるフェイズ
Pessimistic Lock • 悲観的ロック(悲観的並行制御) • トランザクション開始時に対象のロックを取得 • 取得出来ない場合は待つorエラー投げる • ロックを取得
• 安心して更新
Optimistic Lock • 楽観的ロック(楽観的並行制御) • トランザクション開始時のバージョン番号を取得 • ロックは特に取らない • トランザクション進める
• トランザクション終了時に開始時から更新されて いるかをチェック • 変更されていたらエラー投げる(orリトライ)
Optimistic Lock その2 • 実装はtimestampかバージョン番号 • ActiveSupportはlock_versionカラムを用意する と勝手にOptimistic Lockをかける •
cf. ActiveRecord::Locking::Optimistic • http://api.rubyonrails. org/classes/ActiveRecord/Locking/Optimist ic.html
Table-level lock • MyISAMでお馴染みテーブルロック • MEMORYもテーブルロック • 省メモリ、高速 • UPDATE,
DELETEがないときは使える
• 行ロック • ロックコンフリクトが少ない • InnoDB他メジャーなやつはだいたい行ロック • メモリを多く消費する • テーブル全体をロックするクエリが多いときはパ
フォーマンスが低い Row-level lock
Transaction Isolation Level • トランザクションが同時に実行されたときに、どれ くらい分離されるか(影響されないか) • ANSI/ISO SQL標準では4つ定められている •
Serializable • Repeatable Read • Read Committed • Read Uncommitted
Serializable • それぞれのトランザクションは逐次実行した場合 と同じ結果となる • 分離レベルは一番高い • 安全だが低性能
Repeatable Read • 同じ行のデータはトランザクション内で変更され ない • 同じ検索条件で新しい行が出てくること (Phantom Read)がある •
InnoDBのデフォルト分離レベル
Read Committed • コミット済みのデータのみ読み取る • 一度読み込んだデータをもう一度読み込むと データの内容が変更または削除されていること (Non-Repeatable Read)がある •
Phantom Readもある
Read Uncommitted • コミットされてなくても読み込む(Dirty Read) • Phantom, Non-Repeatableもある
トランザクション分離レベル Phantom Read Non- Repetable Read Dirty Read Serializable ×
× × Repeatable Read ◦ × × Read Committed ◦ ◦ × Read Uncommitted ◦ ◦ ◦
InnoDB • 分離レベルは全て対応 • デフォルトはREPEATABLE READ • 全ての接続を変更するときはmy.cnfで • SET
SESSION TRANSACTION ISOLATION LEVEL [LEVEL] でセッションのみも変更可 • SELECT @@tx_isolation; で確認
mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ
| +-----------------+ 1 row in set (0.03 sec)
InnoDB Locks • Record Lock インデックスレコードのロック • Gap Lock インデックス間、最初のインデックスの前、最後のイ
ンデックスの後ろのギャップのロック • Next Key Lock インデックスとインデックスの前のギャップの組み合 わせ
Next Key Lock DEMO
LOCK IN SHARE MODE FOR UPDATE • SELECTと同時にロックを取得 • LOCK
IN SHARE MODE は共有 • FOR UPDATEは排他
FOR UPDATE使わないと... 1. AがBEGIN, SELECT 2. BがBEGIN, UPDATE, COMMIT 3.
AがUPDATE, COMMIT REPEATABLE READだとAが読むデータは3でも 変わらないが、実際データは変更されている。 →1のSELECTをFOR UPDATEにすることで2でロッ ク待ちになる SERIALIZABLEだと常にSELECTがLOCK IN SHARE MODE
MVCC • MultiVersion Concurrency Control • 複数バージョンの同時並行性制御
User A User B SET AUTOCOMMIT=0; SET AUTOCOMMIT=0; time |
SELECT * FROM t; | empty set | INSERT INTO t VALUES (1, 2); | v SELECT * FROM t; empty set COMMIT; SELECT * FROM t; empty set COMMIT; SELECT * FROM t; --------------------- | 1 | 2 | --------------------- 1 row in set
次回は... 決戦!モナド