Transaction and persistence settings
Transactions and persistence answer different questions. Isolation controls concurrent visibility and conflicts. Durability controls what remains after a process or machine failure.
Application transactions
Section titled “Application transactions”Use one connection and commit only after all required database changes succeed. Read transactions for examples and retry handling.
Server modes
Section titled “Server modes”In the standard 1.1.19-rc.12 download, --txn-mode selects an engine, not a session isolation level:
| Engine | Behavior |
|---|---|
occ (default) |
Optimistic engine with commit-time validation |
serializable |
Engine supporting strict serializable transactions when SERIALIZABLE is requested |
fast |
No isolation guarantee; concurrent writers can lose updates. Use only for disposable or controlled single-writer work |
Sessions default to READ COMMITTED under occ and serializable. Request REPEATABLE READ for snapshot isolation or SERIALIZABLE for strict serializable transactions. An explicit level has the same meaning under either engine. Selecting the serializable engine alone does not change the session default.
Use --default-isolation to set the server-wide session default, or select a level through the client or SQL transaction commands. Check the installed version’s help before changing either setting.
Pre-release compatibility
Section titled “Pre-release compatibility”Historical pre-release builds accepted additional engine names. The standard 1.1.19-rc.12 binary rejects occ-v3, zero-copy-occ, table-2pl, serializable-ssi, strict-serializable and row-2pl. These are removed configuration values, not current modes. Removing a name does not invalidate findings about the versions and settings that accepted it.
Persistence is separate
Section titled “Persistence is separate”--wal-sync-mode accepts sync, groupsync and nosync. Durability flags do not select the engine or the session’s isolation level. nosync disables the write-ahead log and cannot preserve acknowledged writes across restart. Review durability before using any benchmark configuration for application data.
Verify your required behavior
Section titled “Verify your required behavior”Test concurrent updates and application invariants with separate connections. Test restart and recovery using the deployment’s actual storage. A setting name or an acknowledged response is not a substitute for a documented guarantee.
Durability · Concurrency · Benchmarks