課題22「トランザクションについて理解する」の対応完了 #68

kamimi01 · 2021-05-02T03:11:08Z

対応内容

以下の対応を行いました。

課題21

依頼事項

以下のご確認をお願い致します。

その他

可能な範囲で、、ご確認お願いいたします！🙇‍♂️

Closes #67

…ub.com/kamimi01/praha_challenge_tasks into feature/task-21-understand-transaction

#7

#67

#7

shimopino

課題1へのコメントを追加しました～

shimopino · 2021-05-02T05:49:31Z

database_basic/understand_transaction/task_1/README.md

+    - 同じ順番でロックする
+      - デッドロックは相手と異なる順番でロックを行おうとする場合に発生するため。
+
+![](https://cloudear.jp/blog/wp-content/uploads/2015/07/deadlock2.png)


この図わかりやすいですね

（今回いろいろ作図をしてみたので、色遣いなど参考になります）

shimopino · 2021-05-02T05:55:05Z

database_basic/understand_transaction/task_1/README.md

+  - データベースで同時に複数のトランザクションが実行される場合に、起こる可能性がある。
+  - テーブル A のロックを取得したトランザクション 1 が、次にテーブル B のロックも取得しようとしている。その一方でテーブル B のロックを取得してトランザクション 2 がテーブル A のロックを取得しようとしている状態。お互いがそれぞれ次にロックを取得したいテーブルのロックの解除を待機する状態になり、トランザクションの処理が止まってしまう。
+  - DBMS は、自動的にデッドロック状態を検出し、デッドロック状態から抜け出すための仕組みが用意されている
+    - MySQL においては、自動的にデッドロック状態を検出し、影響があるいずれかのトランザクションをロールバックする。デッドロックは複数のスレッドが同じロックの取得を待機している状態なため、処理遅延の要因となる。


今回試してないんですが、デッドロック検知によるオーバーヘッドが問題になるケースはあるのか気になりました 🤔

MySQL8.0のデッドロック検出に関しての記述

https://dev.mysql.com/doc/refman/8.0/ja/innodb-deadlock-detection.html

shimopino · 2021-05-02T06:01:34Z

database_basic/understand_transaction/task_1/README.md

+| ------------------ | ---------------------------------- | ---- |
+| 行ロック           | ある特定の 1 行のみをロックする    |      |
+| テーブルロック     | ある特定のテーブル全体をロックする |      |
+| データベースロック | データベース全体をロックする       |      |


データベースロックというのみあるんですね...（初めて知った...）

MySQLで実現できるのかはわからなかったんですが、以下にIBMの資料を載せておきます！

データベースロック

[Oracle] データベース・ロック

検索結果

[duckduckgo] Lock Escalation

DB2のロックエスカレーションについて

ロック・エスカレーション

shimopino · 2021-05-02T06:11:26Z

database_basic/understand_transaction/task_1/README.md

+
+| ロックの厳しさ           | 概要                                                                 | 備考                                                                  |
+| ------------------------ | -------------------------------------------------------------------- | --------------------------------------------------------------------- |
+| 共有ロック               | 他のトランザクションからのデータの参照は可能だが、更新は不可能。<br> | 通常、SELECT 文で選択した行には自動的に共有ロックがかかる。           |


SELECT 文の実行時にロックがかかるということは、以下の実行時に瞬間的にロックがかかっているというイメージであってますかね...

mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from employees where emp_no IN (10001, 10002, 10003); +--------+------------+---------------+-----------+--------+------------+ | emp_no | birth_date | first_name | last_name | gender | hire_date | +--------+------------+---------------+-----------+--------+------------+ | 10001 | 1953-09-02 | Georgi Georgi | Facello | M | 1986-06-26 | | 10002 | 1964-06-02 | Bezalel | Simmel | F | 1985-11-21 | | 10003 | 1959-12-03 | Parto | Bamford | M | 1986-08-28 | +--------+------------+---------------+-----------+--------+------------+ 3 rows in set (0.01 sec) -- ここでロックが一瞬かかっている? mysql> SELECT engine, object_schema, object_name, index_name, lock_type, lock_mode, lock_status, lock_data FROM performance_schema.data_locks; Empty set (0.00 sec)

ありがとうございます！この文章はMySQLのみに限った話ではなかったですが、MySQLの場合はかからないという感じですね。。。！

shimopino · 2021-05-02T06:12:54Z

database_basic/understand_transaction/task_1/README.md

+  - テーブルロックのメリット
+    - 必要なメモリが比較的少なくなる
+    - 単一のロックだけが必要なため、テーブルの大部分に対して使用する場合には高速
+    - データの大部分に対して GROUP BY を頻繁に実行する場合や、テーブル全体を頻繁にスキャンする必要がある場合に高速


こういうユースケースがあるんですね！

shimopino · 2021-05-02T06:17:20Z

database_basic/understand_transaction/task_1/README.md

+|悲観ロック|データそのものはロックせず、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。その確認のために、Versionを管理するためのカラムをもうけて（ロックキーと呼ばれる）、データ取得時のVersionとデータ更新時のVersionを比較する。|Versionのカラム以外にもタイムスタンプを保持する方法もあるが、より精度の高いミリ秒まで保持していたとしても、同時に複数の操作が行われているかの見極めが困難なため、タイムスタンプをロックキーとすることはあまり推奨されていない。|
+|楽観ロック|更新対象のデータを取得する前にロックをかけることで、他のトランザクションから更新されないようにする方式。トランザクション開始直後に更新対象となるレコードのロックを取得する。ロックされたレコードはトランザクションがコミットまたはロールバックされるまで、データの整合性を保証することができる。|`SELECT~ FOR UPDATE`文が利用されることが多い。確実にロックを開放するのが難しいため、ロック状態が長く続くなど発生した場合の回避策が必要。|


ここに関して「楽観ロック」と「悲観ロック」の説明文が反対になっていると思います！

ちなみに自分は「楽観ロック」を使ったことがありません！

ここに関して「楽観ロック」と「悲観ロック」の説明文が反対になっていると思います！

逆でした。。！ご指摘ありがとうございます！

PrismaのDBトランザクションについて

How Prisma Supports Database Transactions

shimopino · 2021-05-02T06:20:24Z

database_basic/understand_transaction/task_1/README.md

+  - 上記の状態になるよう制御するための仕組み。
+  - コミット
+    - トランザクションが終了する際に、トランザクション中の SQL 文によって行われた処理を確定すること
+    - 多くの DBMS では、自動コミットモードがオンの状態で動作するため、1 つのクエリが十国されるたびに自動でコミットを実行する。アプリケーションの実装でオフにすることが可能。（下記に Java のコードあり）MySQLでは`SET AUTOCOMMIT=0;`を実行することでオフにもできる。


「十国」→「実行」でしょうか

実行です。。

shimopino · 2021-05-02T06:21:50Z

database_basic/understand_transaction/task_1/README.md

+    try (Connection db = DriverManager.getConnection(
+        "jdbc:mysql:⁄⁄localhost/sample?serverTimezone=JST&useUnicode=true&characterEncoding=UTF-8&useSSL=true", "root", "12345")) {
+      // 自動コミットモードをオフ
+      db.setAutoCommit(false);


コミットモードはJDBCだとこう設定できるんですね！

ありがとうございます

普段の業務だと自社製のフレームワークを使っているので、あまりJDBCの細かい部分は意識したことがないんですよね...

私は生のJDBCしか見たことがなく。。。
こんなの見たなと思って、載せてみました！

shimopino

課題2のコメントを追加しました～

気になる部分があったのでコメントしてますー

shimopino · 2021-05-02T06:27:26Z

database_basic/understand_transaction/task_2/README.md

+# この段階でターミナル2で以下を実行
+mysql> select * from titles where emp_no = 499942;
+--------+------------------+------------+------------+
+| emp_no | title            | from_date  | to_date    |
+--------+------------------+------------+------------+
+| 499942 | Technique Leader | 1998-03-28 | 2021-05-02 | # コミットされていない変更を見ることができている→ダーティリード
+--------+------------------+------------+------------+
+1 row in set (0.00 sec)
+```


グローバル設定でトランザクションの分離レベルを設定していれば、ターミナルにログインした段階で未コミット状態のデータが見えるんですね。
（自分は実験ごとにセッションで分離レベルを設定していました。）

shimopino · 2021-05-02T06:31:50Z

database_basic/understand_transaction/task_2/README.md

+# ターミナル1で再度検索する
+mysql> select * from titles where emp_no = 499942;
+--------+------------------+------------+------------+
+| emp_no | title            | from_date  | to_date    |
+--------+------------------+------------+------------+
+| 499942 | Technique Leader | 1998-03-28 | 2021-05-02 | # 前回と異なる結果となった→Non-repeatable read
+--------+------------------+------------+------------+
+1 row in set (0.00 sec)


ふとした疑問なんですが、ターミナル1で START TRANSACTION を宣言していない場合、ターミナル1で最初に行った SELECT 文の実行と、2回目の SELECT 文の実行は同一のトランザクション内での処理になるのでしょうか 🤔

autocommitがONの状態で実行しているため、別のトランザクションの処理となってしまっている
ターミナル1でもstart transaction;する必要がある

shimopino

クイズの回答を追加しました！

自分が調査を後回しにしていた機能に関するクイズもあり勉強になりました！
ありがとうございます！！

shimopino · 2021-05-02T06:36:42Z

database_basic/understand_transaction/task_3/README.md

+
+## クイズ2
+
+- MySQLでは、行ロックが解除されるまでInnoDBが待機する時間を定義するシステム変数が存在します。その変数はなんでしょうか？


システム変数 innodb_lock_wait_timeout

トランザクションが行ロックを行う際の待機時間を設定可能

デフォルトは50秒 (1秒～1073741824秒で設定可能)

参考資料

innodb_lock_wait_timeout

ありがとうございます！こちらで回答OKです

shimopino · 2021-05-02T06:44:46Z

database_basic/understand_transaction/task_3/README.md

+- MySQL8.0以降では、ロックに関して`NOWAIT`と`SKIP LOCKED`の機能が新たに追加されました。
+  - この2つがどんな機能か調べてみましょう。


背景

MySQL5.7以前では、トランザクション内でロックを取得する処理を実行した際に、対象レコードがほかのトランザクションにロックされている場合に、行ロックが解放されるまで待機する必要があった

途中でステートメントを終了させるような機能は提供されていなかった

変更点

MySQL8.0から、ロックの取得時に NOWAIT や SKIP LOCKED を設定できるようになった

NOWAIT

対象レコードがすでにロックされている場合にはステートメントをすぐに終了させる

SKIP LOCKED

ロックされたレコードを除外しても問題ない場合は、ロックの解放を待機せずに抽出できた結果セットのみを返す

参考資料

[MySQL 8.0 References] Locking Read Concurrency with NOWAIT and SKIP LOCKED

[MySQL道普請便り] 第123回　ロッキングリードのNOWAITとSKIP LOCKEDオプションについて

[MySQL Server Blog] MySQL 8.0.1: Using SKIP LOCKED and NOWAIT to handle hot rows

SKIP LOCKEDの使いどころは、2つ目の参考資料で提示されている事例がわかりやすかったです。

ユーザーがチケットを購入する際に、チケットレコードの user_id が NULL の値を、ユーザーの先着順で対応する user_id で上書きする処理
この場合は、確かに複数枚存在するチケットの中からどれか1つを取得できればいいため、すでにロックがかかっているレコードは結果セットから除外してもよさそう

shimopino · 2021-05-02T06:53:44Z

（課題内容とは直接関係ないんですが...）
今回のプルリクから、課題の採番は -1 していく感じでしょうか

kamimi01 and others added 10 commits April 30, 2021 22:01

feat: 回答の雛形を作成

836c202

#67

docs: toc-generatorによる目次自動作成

106180f

#7

feat: 課題1の途中と課題3の完了

1f009ff

#67

docs: toc-generatorによる目次自動作成

32e2343

#7

feat: 課題1の完了

f4f6f17

#67

Merge branch 'feature/task-21-understand-transaction' of https://gith…

37a7e89

…ub.com/kamimi01/praha_challenge_tasks into feature/task-21-understand-transaction

docs: toc-generatorによる目次自動作成

53c0dae

#7

feat: 課題2の完了

e1b8c5a

#67

コンフリクト解消 #67

abeb059

docs: toc-generatorによる目次自動作成

fa35b5a

#7

kamimi01 added the データベースの基礎 label May 2, 2021

kamimi01 added this to the 「データベースの基礎」の課題完了 milestone May 2, 2021

kamimi01 requested a review from shimopino May 2, 2021 03:11

kamimi01 self-assigned this May 2, 2021

kamimi01 added this to In progress (Not in review) in PrAha Challenge課題管理 via automation May 2, 2021

shimopino reviewed May 2, 2021

View reviewed changes

kamimi01 changed the title ~~課題21「トランザクションについて理解する」の対応完了~~ 課題22「トランザクションについて理解する」の対応完了 May 2, 2021

kamimi01 merged commit c72208f into develop Jun 25, 2021

PrAha Challenge課題管理 automation moved this from In progress (Not in review) to Done Jun 25, 2021

kamimi01 deleted the feature/task-21-understand-transaction branch June 25, 2021 00:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

課題22「トランザクションについて理解する」の対応完了 #68

課題22「トランザクションについて理解する」の対応完了 #68

kamimi01 commented May 2, 2021

shimopino left a comment

shimopino May 2, 2021

shimopino May 2, 2021

kamimi01 May 2, 2021

shimopino May 2, 2021

shimopino May 2, 2021 •

edited

shimopino May 2, 2021

kamimi01 May 2, 2021 •

edited

shimopino May 2, 2021

shimopino May 2, 2021 •

edited

kamimi01 May 2, 2021

shimopino May 2, 2021

shimopino May 2, 2021

shimopino May 2, 2021

kamimi01 May 2, 2021

kamimi01 May 2, 2021 •

edited

shimopino May 2, 2021

kamimi01 May 2, 2021

shimopino May 2, 2021

shimopino May 2, 2021

kamimi01 May 2, 2021

shimopino left a comment

shimopino May 2, 2021

shimopino May 2, 2021

kamimi01 May 2, 2021

shimopino left a comment

shimopino May 2, 2021

kamimi01 May 2, 2021

shimopino May 2, 2021

shimopino May 2, 2021

shimopino commented May 2, 2021 •

edited

		\|悲観ロック\|データそのものはロックせず、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。その確認のために、Versionを管理するためのカラムをもうけて（ロックキーと呼ばれる）、データ取得時のVersionとデータ更新時のVersionを比較する。\|Versionのカラム以外にもタイムスタンプを保持する方法もあるが、より精度の高いミリ秒まで保持していたとしても、同時に複数の操作が行われているかの見極めが困難なため、タイムスタンプをロックキーとすることはあまり推奨されていない。\|
		\|楽観ロック\|更新対象のデータを取得する前にロックをかけることで、他のトランザクションから更新されないようにする方式。トランザクション開始直後に更新対象となるレコードのロックを取得する。ロックされたレコードはトランザクションがコミットまたはロールバックされるまで、データの整合性を保証することができる。\|`SELECT~ FOR UPDATE`文が利用されることが多い。確実にロックを開放するのが難しいため、ロック状態が長く続くなど発生した場合の回避策が必要。\|


		## クイズ2

		- MySQLでは、行ロックが解除されるまでInnoDBが待機する時間を定義するシステム変数が存在します。その変数はなんでしょうか？

		- MySQL8.0以降では、ロックに関して`NOWAIT`と`SKIP LOCKED`の機能が新たに追加されました。
		- この2つがどんな機能か調べてみましょう。

課題22「トランザクションについて理解する」の対応完了 #68

課題22「トランザクションについて理解する」の対応完了 #68

Conversation

kamimi01 commented May 2, 2021

対応内容

依頼事項

関連リンク

その他

shimopino left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shimopino May 2, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kamimi01 May 2, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shimopino May 2, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kamimi01 May 2, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shimopino left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shimopino left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shimopino commented May 2, 2021 • edited

shimopino May 2, 2021 •

edited

kamimi01 May 2, 2021 •

edited

shimopino May 2, 2021 •

edited

kamimi01 May 2, 2021 •

edited

shimopino commented May 2, 2021 •

edited