DBトランザクション

→データベース関連

一般†

• データベースのロックの基礎からデッドロックまで 2023.4

• DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions - Speaker Deck 2023.4

• DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識 - CARTA TECH BLOG 2022.12

• 排他制御のためだけに渋々 Redis 使ってませんか？ - Speaker Deck 2022.11
  • ロックするものがない場合に、Redisのアトミック機能よりもDBMSのアドバイザリーロック機能を使った方がよいという話

• ダーティリード、ノンリピータブルリード、ファントムリードを起こして挙動を確認してみた｜SHIFT Group 技術ブログ｜note 2022.8

• トランザクションの隔離とは
• 同時実行@宇宙仮面のC#プログラミング
• トランザクション分離レベル 読み取り一貫性のサポートとロックエスカレーション

ANSI標準の４つの分離レベル(アイソレーションレベル）†

• MySQLのトランザクション分離レベルとアノマリーについて調べてみた 2023.12

• READ UNCOMMITED
  • もっとも安全度低い
  • 他プロセスがトランザクション中にUPDATEしたデータをCOMMITする前にSELECT(ダーティリード)可能

• READ COMMITED
  • デフォルトの分離レベル。引数なしでBeginTrans()するとこれになる(SQL Server 2005)
  • ダーティリード不可
  • 自分のトランザクション中に、自分がSELECTしただけのレコードは他プロセスがUPDATE-COMMITできる（＝反復不可能読み取りが可）
  • つまり、自分のトランザクション中のSELECT結果の一貫性が保証されない
  • READ_COMMITED_SNAPSHOTオプションの状態によって動作が異なる
    • OFFのとき、トランザクションにひっかかったクエリは待たされる
    • ONのとき、トランザクションにひっかかったクエリは、トランザクション開始前の状態を取得し、ロック待ちをしない

• REPEATABLE READ
  • ダーティリード不可
  • 自分のトランザクション中に、自分がSELECTしただけのレコードも他プロセスがUPDATE-COMMITできない（＝反復不可能読み取りが不可）
  • 自分のトランザクション中に、自分がSELECTした条件にマッチするレコードをINSERT可能（＝ファントム発生可）
  • つまり、自分のトランザクション中のSELECT結果は、その時点で存在していたレコードについては同じであることが保証されるが、存在していなかったレコードが追加されている可能性はある

• SERIALIZABLE
  • ダーティリード、反復不可能読み取り、ファントム発生すべてが不可
  • トランザクションのSELECT結果は外部からの影響を一切受けないことが保証される

最新の50件