SERIABLIZABLE レベルでテーブルに行を挿入するトランザクション t1 があるとします。SERIABLIZABLE レベルではない別のトランザクション t2 があり、select * from table_foo によって同じテーブルからすべての行を選択します。
私の質問は、t1 がロックをコミット/解放する前に、t2 は t1 による行の挿入を確認できますか?
SERIABLIZABLE レベルでテーブルに行を挿入するトランザクション t1 があるとします。SERIABLIZABLE レベルではない別のトランザクション t2 があり、select * from table_foo によって同じテーブルからすべての行を選択します。
私の質問は、t1 がロックをコミット/解放する前に、t2 は t1 による行の挿入を確認できますか?
T1 が T2 の前に実行されると仮定します。T2 は T1 を待機するため、T2 には行が表示されません。
T1 が実行を開始すると、テーブルをロックして最大の分離レベルを保証します。つまり、T1 が完了するまで、このテーブルで他のトランザクションは実行されません。
他のトランザクションがテーブルを使用しようとすると (この場合は T2)、待機する必要があります。
したがって、T1 と T2 が同時に (同時に) 実行されることはありません。例えば:
T2 は T1 を待機します
T1 が完了すると T2 が実行されます
T2 には、T1 によって挿入された行が表示されます
(コメント領域には長すぎます) はい、各トランザクションを順次実行する必要がある場合は、データベースの分離レベルとして SERIALIZABLE を設定することもできます。
理論的には、各トランザクションは (ACID プロパティの I を達成するために) 分離して実行する必要がありますが、実際にはあまり意味がありません。それはすべてパフォーマンスの問題です。同時実行性の高いアプリケーションのデータベースは、この方法では適切に実行できませんでした。
アイデアは、分離とパフォーマンスのバランスをとることです。分離レベルを下げると (たとえば、一般的にデフォルトの分離レベルである COMMITTED READ)、更新の消失、反復不可能な読み取り、ファントム読み取りなどの問題が発生する可能性があります。通常、このリスクは許容可能であり、これらの状況に対処する必要がある特定のトランザクションでのみ分離レベルを上げることも制御できます。