Transactions and locks
Transaction rollback and cross-process coordination solve different problems.
Examples use Classic and Fluent tabs. Your choice follows you through the manual.
Choose the transaction boundary
| Mode | Behavior |
|---|---|
| PerMigration | Default. Each successful migration commits independently. |
| None | Provider/operation transaction behavior; no runner-managed migration transaction. |
| WholeSession | One session transaction on SQLite, PostgreSQL or SQL Server; history initialization happens first. |
Actual atomicity depends on the database and operation. Administration commands or implicit-commit DDL can violate assumptions. AfterUp/AfterDown run after commit; WholeSession defers them until the session commit. A callback failure cannot undo durable changes.
Classic
runner.Options.TransactionMode = MigrationTransactionMode.WholeSession;
runner.MigrateToLastVersion();Fluent
runner.Options.TransactionMode = MigrationTransactionMode.WholeSession;
runner.MigrateToLastVersion();Shared host · both styles
Coordinate competing runners
DatabaseMigrationLock uses SQL Server application locks, PostgreSQL advisory locks or MySQL/MariaDB named locks. The lease is session-owned and remains held across migration commits. This host fragment assumes a supported provider; SQLite rejects this built-in lock.
Classic
runner.Options.Lock = new DatabaseMigrationLock();
runner.Options.LockTimeout = TimeSpan.FromSeconds(60);
runner.MigrateToLastVersion();Fluent
runner.Options.Lock = new DatabaseMigrationLock();
runner.Options.LockTimeout = TimeSpan.FromSeconds(60);
runner.MigrateToLastVersion();Shared host · both styles
Scope of protection
Native locks are keyed by database, history table and scope. Coordinate separately if different scopes modify shared objects. Do not close/replace the connection, switch databases or manipulate the native lock inside a migration. MySQL named locks coordinate one server, not an entire distributed cluster.
Implement IMigrationLock for another lease mechanism, or serialize deployments outside the process. A transaction, history primary key or ordinary database write lock alone does not prove that the whole migration sequence is serialized.