S-JIS[2021-09-18/2023-10-05]

Tsurugi select for updateの考察

Tsurugiでselect for updateに相当する処理について。

概要

トランザクション分離レベルREAD COMMITTED（PostgreSQLやOracleのデフォルト）でよく使われるselect for updateで排他する方式（悲観ロック）は、Tsurugiでは使わない（使えない）。

Tsurugiのトランザクション分離レベルはSERIALIZABLEなので、トランザクションの処理内容が競合するとシリアライゼーションエラー（リトライ可能な アボート）になる。その際に再実行（リトライ）するという方式（楽観ロック）がTsurugiの方式。
（リトライはアプリケーション側で行う必要がある。Javaの場合、Iceaxeにリトライする仕組みが用意されている）

理論的には、悲観ロックでも楽観ロックでも同じ結果になるらしい。
後述の例のように、いくつかを試してもその通りになる。

しかしプログラミング方法や挙動は異なる。

• 悲観ロック（select for update）
  • プログラマーが排他制御を行う（for updateを記述する）必要がある。
    • 排他制御を誤るとデッドロックすることがある。
  • トランザクションが失敗することは（ほぼ）無い。
  • ロックをとる処理は実行負荷が高い。
    • 滅多に競合しないのであれば、無駄なロックが多くなってしまう。
• 楽観ロック（Tsurugi）
  • プログラマーがselect for updateで排他制御を行う必要は無い。
    • 当然、デッドロックが起きることも無い。
  • トランザクションがシリアライゼーションエラー（リトライ可能なアボート）になることがある。その場合、アプリケーション側でトランザクション （実行したSQL全て）を先頭から再実行（リトライ）しなければならない。
  • シリアライゼーションエラーかどうかを確認する処理の負荷は低い。
    • リトライは実行負荷が大きいが、滅多に競合（リトライ）しないのであれば、無駄は少ない。
      • OCCは（優先度が低くてアボートしやすいので）、実行時間が短い処理で使用することが推奨されている。（実行時間が短ければ、リトライもすぐに済む）

TODO+++---Tsurugiでは、for updateは実際どう扱われるか？（エラーになりそう）

実行例

2つのトランザクションT1とT2を同時に実行する例を考えてみる。
SERIALIZABLEの場合、T1→T2またはT2→T1の順で実行したのと同じ結果になるはずなので、悲観ロックと楽観ロックが同じ結果になることを確認したい。

更新系トランザクションの例

例として、以下のようなテーブルとデータがあるものとし、T1は「xを+1」「yを+1」、T2は「xを+10」「yを2倍」する処理とする。

create table example (
  k int primary key,
  x int,
  y int
);
insert into example values(1, 100, 200);

このとき、T1とT2を直列に実行すると、T1→T2およびT2→T1はそれぞれ以下のようになる。

xは111となり、yは402または401となる。
（つまり、SERIALIZABLEで並列に実行すればこれと同じ結果になるはず、ということ）

次に、READ COMMITTED（排他なし）でT1とT2を並列に実行することを考えてみる。

この場合、T1のコミットがT2より遅ければxが101・yが201、逆であればxが110・yが400で、T1・T2を順番に実行（T1→T2またはT2→T1）したのとは全く違う結果になってしまう。

ただ、こういう処理の場合、READ COMMITTEDではselect for updateでロックする。
そうすると以下のようになる。

これなら、T1・T2を順番に実行したのと同じ結果になる。

同じ処理を、Tsurugi（SERIALIZABLE）で実行するとどうなるか？
Tsurugiでは更新を伴うトランザクションの実行方法（トランザクション種別）はOCCとLTXの2種類があるが、OCCの挙動は以下のようになる。

Tsurugiでは、遅くともコミット時に、処理したデータが他のトランザクションによって更新されていないかどうかチェックされ、更新されている場合はシリアライゼーションエラー（リトライ可能な アボート）が発生する。
シリアライゼーションエラーが発生したら、そのトランザクションの処理を先頭から再実行（リトライ）すれば、今度は（同時に実行される競合トランザクションは無くなっているので）コミットが成功する。

LTXの場合は以下のような挙動になる。

LTXの場合、優先度が低い側が先にコミットすると、優先度が高いLTXが終わるまで待つ。
優先度が高いLTXが終わったら、処理したデータが他のトランザクションによって更新されていないかどうかチェックされ、更新されている場合はシリアライゼーションエラー （リトライ可能なアボート）が発生する。
シリアライゼーションエラーが発生したら、そのトランザクションの処理を先頭から再実行（リトライ）すれば、今度は（同時に実行される競合トランザクションは無くなっているので）コミットが成功する。

OCCもLTXも、多少の違いはあれど、シリアライゼーションエラーが発生したらトランザクションを再実行（リトライ）することで、最終的にT1・T2を順番に実行したのと同じ結果になっている。
これがSERIALIZABLE（Tsurugi）の挙動である。

読み込みのみのトランザクションの例

T1が同じデータを2回読み、T2でそのデータを更新する例を考えてみる。
以下のようなテーブルとデータがあるものとする。

create table example (
  k int primary key,
  x int
);
insert into example values(1, 100);

T1とT2を直列に実行すると、T1→T2およびT2→T1はそれぞれ以下のようになる。

ご覧の通り、T1のselectは2回とも同じ値を読み出している。

では、READ COMMITTED（排他なし）でT1とT2を並列に実行するとどうなるか考えてみよう。

ちょっと恣意的だが、T1の2回のselectの間にT2で当該データを更新・コミットすると、T1のselectは、1回目と2回目で異なる結果になってしまう。

もちろんこれも、select for updateでロックすれば同じデータが読める。

一方TsurugiのOCCでは、以下のようになる。

Tsurugiでは、コミット時にトランザクションの内容がSERIALIZABLEかどうか（今回のケースでは、selectが同じ値を読んでいるかどうか）をチェックする。
今回のT1の初回はシリアライゼーションエラー（リトライ可能なアボート）となり、リトライ後はselectが2回とも同じ値を読んでいる。
これにより、T2→T1の順で実行したのと同じ結果になっている。
※このように、Tsurugiではselectのみのトランザクションであってもアボートすることがある（ので、必ずコミットして、コミットが成功することを確認しなければならない）。

LTXの場合は以下のようになる。

この場合、T1→T2の順で実行したのと同じ結果になっている。