Transactions

A transaction is a group of database statements that either all take effect or none do. Commit makes the whole group permanent. Rollback discards all of it. There is no half-finished state for other connections to read.

This matters wherever a change needs more than one statement. Cancelling an order sets a status, returns stock to several products and writes an audit row. Those writes must not be allowed to disagree with each other.

Before reaching for transaction code, though, find out how much you already have.

Order order = new()
{
    CustomerId = customerId,
    OrderDate = DateTime.UtcNow,
    Status = OrderStatus.Open
};

order.Items.Add(new OrderItem { ProductId = 91, Quantity = 2, UnitPrice = 24.99m });
order.Items.Add(new OrderItem { ProductId = 44, Quantity = 1, UnitPrice = 7.50m });

context.Orders.Add(order);

// No transaction code here, and the four rows are still atomic.
await context.SaveChangesAsync();

• Adding the parent is enough. EF Core walks the navigation property, finds the items, and inserts them as well.
• The order Id does not exist until the insert runs. EF Core reads the generated key back and sets OrderId on each item, in that sequence, before inserting them.
• If the second item violated a foreign key, the whole batch would roll back. You would not be left with an order and one item, which is exactly the state that makes data hard to trust later.

BEGIN TRANSACTION;

INSERT INTO [Orders] ([CustomerId], [OrderDate], [Status])
OUTPUT INSERTED.[Id]
VALUES (@p0, @p1, @p2);

INSERT INTO [OrderItems] ([OrderId], [ProductId], [Quantity], [UnitPrice])
VALUES (@p3, @p4, @p5, @p6), (@p7, @p8, @p9, @p10);

COMMIT;

• The BEGIN and the COMMIT were not in your code. EF Core added them because the save needed more than one statement.
• The two order items went in as a single INSERT with two rows. EF Core batches statements to cut round trips, which is part of why saving once beats saving in a loop.
• When a save needs only one statement, EF Core may skip the explicit transaction. A single statement is already atomic, so there is nothing to wrap.

await using IDbContextTransaction transaction =
    await context.Database.BeginTransactionAsync();

try
{
    order.Status = OrderStatus.Cancelled;
    await context.SaveChangesAsync();

    // Returns stock to each product, and calls SaveChanges itself.
    await RestoreStockAsync(context, order);

    await context.Database.ExecuteSqlAsync(
        $"INSERT INTO [OrderAudit] ([OrderId], [Action]) VALUES ({order.Id}, 'Cancelled')");

    await transaction.CommitAsync();
}
catch
{
    await transaction.RollbackAsync();
    throw;
}

• BeginTransactionAsync opens a transaction on the connection. Every statement afterwards joins it, whether it came from SaveChanges or from raw SQL.
• Nothing is permanent until CommitAsync. If RestoreStockAsync throws, the status change is discarded with it.
• The catch rolls back and re-throws. Swallowing the exception here would leave the caller believing the cancellation succeeded.
• await using means that if an exception escapes before the commit, disposing the transaction rolls it back anyway. The explicit rollback is there to make the intent obvious to the next reader.