Transactions and Isolation

Every SQL statement runs in an implicit transaction unless the session already has an explicit BEGIN/COMMIT/ROLLBACK transaction.

The default cursor-stability mode applies writes directly with undo masks, gives statement atomicity, and rolls back on errors. MemCP also contains an ACID mode with snapshot visibility and optimistic commit conflict detection. Savepoints are used internally for nested trigger/error recovery.

Transaction state is tracked per shard. Visibility includes main rows, delta rows, insert/delete overlays, transaction snapshot, and the active shard generation. Commit locks and publishes touched shards; rollback reverses staged or directly applied changes. Nested shard work has a bounded fanout to avoid deadlock and goroutine explosion.

For safe tables, WAL synchronization occurs at commit. logged writes WAL without fsync; sloppy, memory, and cache skip WAL durability. A transaction spanning tables therefore inherits the guarantees and risks of each table's ENGINE.

MemCP does not claim every MySQL isolation level, XA, or distributed transaction feature. Test conflicts and failure recovery required by the application.