SQLite の DEFERRED トランザクションの有用性を見出せない2021年07月11日 13時35分23秒

SQLite の IMMEDIATE EXCLUSIVE DEFERRED トランザクションの違いを取り上げたが、この時は自分で SQLite の実装を調べるのが主だった。

その後、SQLite の DEFERRED トランザクションを更に詳しく調べているが、その有用性を見出せない。まず、簡単な復習として、DEFERRED トランザクションはロックの取得の予約を行う行為。実際には SELECT で読み出しを、INSERT/UPDATE/DELETE 等で書き込みを行うまでは実際にロックを取得をしない。

そのため、先に TRANSACTION を始めたのに、他のセッションに書き込みを許してしまう。

terminal-1% sqlite3 test.sql
sqlite > CREATE TABLE a ( int f );
sqlite > BEGIN DEFERRED TRANSACTION;
sqlite >
terminal-2% sqlite3 test.sql
sqlite > INSERT INTO a VALUES ( 2 ); 
sqlite > SELECT * FROM a;
2
sqlite >
terminal-1% sqlite > INSERT INTO a VALUES ( 1 ); 
sqlite > SELECT * FROM a;
2
1
sqlite >
terminal-2% sqlite > ISELECT * FROM a;
2
sqlite >
terminal-1% sqlite > COMMIT; 
sqlite > SELECT * FROM a;
2
1
sqlite >
後からきた terminal2 が先にデータベースにレコードを挿入してしまっている。

一意性を保つためのトランザクションのはずが、他のセッションに書き込みを許してしまっている。ただ、SQLite は複数のセッションを前提としていないのでこれでも大丈夫との意見もあるが、業々、分かりづらい動作になっている様にしか見えない。単一セッションでの利用が前提であったとしても、IMMEDIATE トランザクションで事が足りる様に見える。

前回