トランザクション - 泥府湾日誌

読んでいて首をひねる個所が複数あった。

まぁ「何でselectを一つかける前にトランザクション開始したんだ」「rollbackまで一度に書いてから貼れ」っていうのは置いておこう。

なぜselect一つを実行しただけでテーブルのロックがかかったのかと考えると、どう考えても「ファントムリード対策（トランザクション内部で同じセレクトを発行したのに違う結果が返ってくる可能性があるのでそれを予防する）」が発動していると考えられる。

DBのトランザクションってそこまで考慮してくれたっけ？と思って「トランザクションレベル」で検索すると、PostgreSQLのマニュアルがヒットした。

「リピータブルリード」か「シリアライザブル」を指定してある場合、ファントムリードが起こらないとされているのでロックはかかるようだ。（バージョンによって若干表記が異なる。）

デフォルトがリピータブルリードらしいので、selectだけでもテーブルロックは発生するようだ。

文中で「明示的ロック」についてのPostgreSQLのマニュアルが引かれているが、それはトランザクションが行ったテーブルロックなので、トランザクションの問題としてはトランザクション分離レベルについて言及するのが正しい。

MySQLでもロックはかかるようなのだが、新しいマニュアルは英語だけだったのでまじめに読んでいない。だが「レコード単位のロックをする」と書かれているようにも見える。

普通は「selectを一回発行するだけならトランザクションはいらない」「beginからrollbackまでまとめて書いて実行する」のどちらかになると思う。

あるいは「トランザクションレベルを下げる」である。最低レベルの「リードアンコミッティド」で機能的には十分だろうし、それなら多分ロックされない。

という項を引いているが、マニュアルを見るところが違う。この件で参照するのはここだ。

table lockは明示的にテーブルをロックする命令で、rollbackはトランザクションを巻き戻す命令。系統が違う。

13.3.5.1冒頭の「LOCK TABLES はトランザクションセーフではないため、テーブルをロックしようとする前に、アクティブなトランザクションをすべて暗黙的にコミットします。」という冒頭の文章を読んで気が付いてほしいところである。

気が付いていないという事はトランザクション中にテーブルロックを明示的に使ってしまって、コミットしてはいけないデータをコミットしてしまうという事故を将来起こす可能性があるので危険である。

逆に「セッションが (たとえば、START TRANSACTION で) トランザクションを開始した場合は、暗黙的な UNLOCK TABLES が実行され、既存のロックが解放されます」という記述もあった。

引用されている個所は「トランザクションによって発行されたテーブルロックはロールバックで解除されるが、トランザクション中でユーザーが明示的に行ったテーブルロックはトランザクションの対象にならないので解除されない」と書かれているだけだろう。