Test an isolation level's behavior

Verify repeatable reads inside a transaction: a concurrent writer's rolled-back insert must not change a second read of the same aggregate.

1. 1CREATE TEMP TABLE readings (label TEXT NOT NULL, total INTEGER NOT NULL).
2. 2BEGIN; record 'first_read' = SUM(stock) of cameras into readings.
3. 3Simulate the other writer: SAVEPOINT other_writer; insert product sku 'CAM-900', name 'Phantom Cam', category 'cameras', price 99, stock 50; ROLLBACK TO other_writer; RELEASE other_writer.
4. 4Record 'second_read' = SUM(stock) of cameras, then COMMIT.
5. 5Verify: SELECT COUNT(*) AS reads, COUNT(DISTINCT total) AS distinct_values FROM readings returns (2, 1).

• temp.readings holds two identical camera stock readings
• The last result set is (2, 1)
• The script uses a SAVEPOINT

• Every run starts from a freshly seeded database, so your script must include its own setup statements.
• The workbench has a single connection, so concurrent sessions are simulated step by step inside one session (snapshots in TEMP tables, SAVEPOINTs as the other transaction).
• SQLite always runs SERIALIZABLE; PRAGMA read_uncommitted only matters in shared-cache mode.
• Only the last result set of your script is compared, so finish with the verification query.