Innovabit.DotNet.Interceptors.Transactions.Abstractions 2.0.117

Innovabit.DotNet.Interceptors.Transactions.Abstractions

Declarative database transactions for Innovabit.DotNet.Interceptors via a [Transactional] attribute. This is the provider-agnostic base: it ships the interceptor, the attribute and the ITransactionManager abstraction. Pick a provider to actually open transactions:

• Innovabit.DotNet.Interceptors.Transactions.EntityFrameworkCore — on a DbContext.
• Innovabit.DotNet.Interceptors.Transactions.SystemTransactions — on TransactionScope.
• Innovabit.DotNet.Interceptors.Transactions.AdoNet — on a raw DbConnection (Dapper, ADO.NET).

Usage

services
    .AddInterceptors()
    .AddEntityFrameworkCoreTransactions<OrderDbContext>();   // or .AddTransactionScope() / .AddAdoNetTransactions()

services.AddScopedWithInterception<IOrderService, OrderService>();

public class OrderService(OrderDbContext db) : IOrderService
{
    // One transaction around the whole method: committed on return, rolled back on exception.
    [Transactional]
    public async Task PlaceAsync(Order order, CancellationToken cancellationToken)
    {
        db.Orders.Add(order);
        await db.SaveChangesAsync(cancellationToken);

        // Joins the transaction above — nothing is persisted unless both steps succeed.
        await _inventory.ReserveAsync(order, cancellationToken);
    }
}

The method's own CancellationToken argument (if it has one) is flowed into the commit/rollback, so a cancelled call does not leave transaction work running past it.

Lifetimes

Register the interceptors scoped — AddInterceptors() with no argument, which is the default. Providers register their ITransactionManager as scoped (a DbContext or a connection is scoped), so AddInterceptors(ServiceLifetime.Singleton) would make the interceptor a captive of a scoped dependency and DI fails at resolution. Resolve the intercepted service from a scope, the way a web request or a message handler already does.

[Transactional]

Propagation

Not every provider can nest transactions: RequiresNew throws NotSupportedException on the Entity Framework Core and ADO.NET providers (a single connection cannot hold two independent transactions). Use the TransactionScope provider when you need it.

Read-only methods

[Transactional(ReadOnly = true)] still opens a transaction — so a multi-query read sees one consistent snapshot — but always finishes it with a rollback. A write that slips into a read path therefore never reaches the database instead of being silently committed.

Selective rollback

// The order row survives: a rejected payment is a business outcome worth persisting.
[Transactional(NoRollbackOn = new[] { typeof(PaymentDeclinedException) })]
public Task ChargeAsync(Guid orderId) { ... }

NoRollbackOn takes precedence over RollbackOn, so a broad rule can be narrowed with specific exclusions. The exception is re-thrown either way — the choice is only about committing or undoing the work already done.

Ordering

The interceptor runs at InterceptorOrders.Transaction (700), the innermost position on the default scale. That matters when it is combined with retry (500): each retry attempt gets its own fresh transaction, instead of reusing one the previous failure already poisoned.

Writing a provider

Implement ITransactionManager (plus the ITransaction handle it returns) and register it in DI alongside AddTransactions():

public static InterceptorBuilder AddMyTransactions(this InterceptorBuilder builder)
{
    builder.Services.TryAddScoped<ITransactionManager, MyTransactionManager>();
    return builder.AddTransactions();
}

The interceptor — not the manager — applies the propagation rules: it reads ITransactionManager.HasActiveTransaction and only calls Begin/BeginAsync when a new transaction must be opened. A manager that cannot nest should throw NotSupportedException when TransactionSettings.Propagation is RequiresNew.

License

MIT