You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Shared DbContext and Transaction Across Handlers in Wolverine Within a Single Request Scope in a Modular Monolith .NET Application #2517
Hello, I want to develop a modular monolith .NET application. My main goal is to ensure that all modules in the project do not reference each other directly and that each module works with its own DbContext object.
While modules use different DbContext objects, I want to proceed by sharing a common connection and transaction (wrapping the entire request lifetime with an in-memory transaction, without using outbox or inbox patterns). For this purpose, I defined a Wolverine DbContext object globally and aim to pass its connection and transaction to other modules.
My problem is this: the “Wolverine DbContext” object I obtain in the handler of Module 1 is different from the “Wolverine DbContext” object I obtain in the handler of Module 2 (even though it is registered as scoped). I assume that Wolverine creates a new DI scope for each handler, which causes the object to be recreated.
Is it possible to use the same scope throughout the request lifetime so that all handler calls can share common dependencies? If yes, how can I achieve this?
Nope, nope, nope. Sorry, I want absolutely nothing to do with that!
"I assume that Wolverine creates a new DI scope for each handler, which causes the object to be recreated" -- yikes, no, not sure where you got that from.
My consistent advice in anything like this is:
You should never need to have a transaction that spans multiple DbContext objects
So either change your DbContext boundaries because they're wrong, or...
use eventual consistency between modules if you must.
I'm converting this to a discussion in case someone else has something better to add.
Activity
jeremydmiller commentedon Apr 15, 2026
Nope, nope, nope. Sorry, I want absolutely nothing to do with that!
"I assume that Wolverine creates a new DI scope for each handler, which causes the object to be recreated" -- yikes, no, not sure where you got that from.
My consistent advice in anything like this is:
I'm converting this to a discussion in case someone else has something better to add.