Default SaveChanges Transactions, Explicit Transactions, Isolation Levels, and Scope

Learning outcomes

Chapter 13 taught how one row detects a stale writer. Transactions answer a different question: which database operations must succeed or fail as one unit, and what can concurrent sessions observe while that unit is in progress? A transaction is a database boundary around work; atomicity means either the committed unit becomes durable as a whole or its uncommitted changes are rolled back. Isolation controls how concurrently executing transactions can observe and interfere with one another.

1. One SaveChanges is already an atomic unit when the provider supports transactions

For relational providers that support transactions, EF Core wraps all modification commands generated by one SaveChanges call in a transaction. If one command fails, the call is rolled back so earlier commands from that same save do not remain committed. That default is usually sufficient when one unit of work can be expressed as one SaveChanges.

var order = await db.WorkOrders.SingleAsync(x => x.Id == id, ct);order.ReviseSummary("Replace bearing and inspect coupling");order.AdvanceRevision();db.Set<OutboxMessage>().Add(new OutboxMessage{    Id = Guid.NewGuid(),    OccurredUtc = clock.GetUtcNow().UtcDateTime,    Type = "WorkOrderChanged",    PayloadJson = BuildMinimalOutboxPayload(order)});await db.SaveChangesAsync(ct); // tracked update + outbox insert are one SaveChanges unit

This is the strongest reason not to open an explicit transaction ceremonially. Extra transaction code adds failure paths and can conflict with retrying execution strategies without increasing correctness when a single SaveChanges already defines the intended atomic boundary.

2. Deliberately wrong: assume two SaveChanges calls are one transaction

order.ReviseSummary("Parts approved");order.AdvanceRevision();await db.SaveChangesAsync(ct);          // can commit hereawait billingClient.ReserveBudgetAsync(..., ct); // remote call can failorder.ReviseSummary("Scheduling metadata prepared");order.AdvanceRevision();await db.SaveChangesAsync(ct);          // separate database transaction

The first SaveChanges can be durable even if later work fails. Worse, holding a database transaction open while calling a remote service would trade one inconsistency for long lock duration and uncertain latency. The repair is architectural: keep remote I/O outside a database transaction and use durable workflow/outbox semantics, or—when all operations are in the same database—group the necessary SaveChanges calls in one short explicit transaction.

3. Explicit transaction: two saves, one commit decision

await using var tx = await db.Database.BeginTransactionAsync(ct);try{    var order = await db.WorkOrders.SingleAsync(x => x.Id == id, ct);    order.ReviseSummary("Bearing replacement authorized");    order.AdvanceRevision();    await db.SaveChangesAsync(ct);    db.Set<OutboxMessage>().Add(new OutboxMessage    {        Id = Guid.NewGuid(),        OccurredUtc = clock.GetUtcNow().UtcDateTime,        Type = "WorkOrderAuthorized",        PayloadJson = BuildMinimalOutboxPayload(order)    });    await db.SaveChangesAsync(ct);    await tx.CommitAsync(ct);}catch{    await tx.RollbackAsync(ct);    throw;}

Both SaveChanges calls now participate in the same database transaction. Notice that the outbox remains local database work; publishing the message still happens after commit in a separate dispatcher.

4. Isolation is a database contract, not an EF slogan

Microsoft.Data.Sqlite documents SQLite transactions as serializable by default. It also documents that only one transaction can have pending writes at a time. SQL Server, PostgreSQL, MySQL/MariaDB, and Oracle implement concurrency differently; passing an IsolationLevel enum to EF does not erase those engine rules.

5. Observe from a second connection

The lab uses a separate physical connection so the first context's identity map cannot be mistaken for database isolation evidence. On SQLite, the important result after a write may be blocking, not a non-blocking stale read.

await using var writer = await factory.CreateDbContextAsync(ct);await using var tx = await writer.Database.BeginTransactionAsync(ct);var order = await writer.WorkOrders.SingleAsync(x => x.Id == id, ct);order.ReviseSummary("transaction-visible after commit");order.AdvanceRevision();await writer.SaveChangesAsync(ct);// Use a short timeout for the observation probe. Microsoft.Data.Sqlite// documents that a pending write can block another connection.try{    await using var observer = new SqliteConnection(        "Data Source=servicehub-lab.db;Default Timeout=1");    await observer.OpenAsync(ct);    await using var command = observer.CreateCommand();    command.CommandText = "SELECT summary FROM work_orders WHERE work_order_id = $id";    command.Parameters.AddWithValue("$id", id);    Console.WriteLine(await command.ExecuteScalarAsync(ct));}catch (SqliteException ex){    Console.WriteLine($"Pre-commit observer blocked/failed: {ex.SqliteErrorCode}");}await tx.CommitAsync(ct);await using var after = await factory.CreateDbContextAsync(ct);Console.WriteLine(await after.WorkOrders.AsNoTracking()    .Where(x => x.Id == id)    .Select(x => x.Summary)    .SingleAsync(ct));

Microsoft.Data.Sqlite documents that after a SQLite transaction performs its first write, concurrent access can be blocked until the transaction completes. Therefore the pre-commit probe may time out rather than return an “old” row. That blocked/timeout evidence is itself part of the isolation/locking observation. After commit, a fresh context should read the new durable value.

6. Choosing an isolation level needs an anomaly and workload, not a magic “strong” value

await using var tx = await db.Database.BeginTransactionAsync(    System.Data.IsolationLevel.Serializable,    ct);

Ask which invariant requires protection, what rows/ranges participate, and how much blocking/retry is acceptable. For SQLite the default is already serializable; Snapshot and Chaos are not supported by Microsoft.Data.Sqlite. Other engines may support snapshot-style isolation, predicate/range locking, or MVCC semantics under differently named levels. Verify the actual provider/database documentation and test from separate sessions.

7. Transaction events are observable

optionsBuilder.LogTo(    Console.WriteLine,    new[]    {        DbLoggerCategory.Database.Transaction.Name,        DbLoggerCategory.Database.Command.Name    },    LogLevel.Information);

Transaction logs can show begin/commit/rollback and command ordering. They do not prove database-side lock duration, blocked sessions, deadlock graphs, or execution plans. Combine EF evidence with engine-specific diagnostics in production.

8. Hands-on lab

1. Reset servicehub-lab.db and enable command + transaction logging.
2. Perform one SaveChanges containing a WorkOrder update and outbox insert; capture transaction logs.
3. Repeat as two SaveChanges without an explicit transaction and note two independent commit boundaries.
4. Wrap the two saves in BeginTransactionAsync; deliberately throw before commit and verify both database effects roll back.
5. Run the second-connection probe with a short timeout before commit; record whether it blocks/times out, then verify the committed value afterward.
6. Print tx.GetDbTransaction().IsolationLevel and record the actual SQLite result.
7. Attempt only documented SQLite isolation levels; record provider errors instead of forcing unsupported settings.
8. Document how the production provider differs before reusing the same transaction policy.

9. Production judgment and bridge

Use the smallest transaction that protects the real invariant. Keep provider isolation/locking semantics explicit, measure contention, and verify visibility from other sessions. Lesson 2 zooms into a transaction that remains open across multiple save attempts: EF savepoints and the tracker reconciliation required after partial rollback.

Authoritative references

• Using Transactions - EF Core — default SaveChanges atomicity, explicit transactions, savepoints, cross-context transactions, and System.Transactions.
• Transactions - Microsoft.Data.Sqlite — SQLite concurrency, isolation, deferred transactions, and savepoints.
• ADO.NET limitations - Microsoft.Data.Sqlite — unsupported SQLite isolation levels and System.Transactions limitation.
• Simple Logging - EF Core — database command/transaction logging for development evidence.
• Handling Concurrency Conflicts - EF Core — optimistic version conflicts as a separate mechanism from transaction isolation.