We currently run NSB 5 with a RavenDB for business data persistence using a fairly traditional MSMQ + RavemDB + DTC configuration for the transport.
Given the issues Particular have highlighted around Raven + DTC under load we are in the process of migrating from DTC to outbox.
Our existing implementation has separate Raven DB connection strings, document stores, document session initialisation and associated IoC wire-up (using structure map) for the business data persistence and the transport persistence. For the initial Outbox migration the team have kept these separate Raven sessions.
Whilst the documentation around the RavenDB Outbox documentation doesn’t explicitly state this, my understanding of how Outbox works relies on the business data and the NSB persistence sharing the same database transaction to achieve atomic updates - therefore they should share a single document session?
Does anybody else have any experience running an NSB 5 implementation with Raven DB for both business and transport persistence with Outbox? Should we be using the shared document session and in which case how is this configured?
Hi Particular team - I would really appreciate some feedback on this topic. Given the DTC bug you have highlighted it would be good to get a very unambiguous statement in how to implement Outbox correctly for Raven over both business and transport data. ‘UseSharedSession’ config option appears to be broken in NSB 5.0.
I’ve reopened the original issue. The current behavior for customizing the session is broken at run-time. Please let us know if you require this API or if the default session sharing which is activated the Outbox is enough.
Thanks for getting back to me. So we should just be using the persistence.SetDefaultDocumentStore rather than using persistence.UseSharedSession. Would be good to flag this issues with UseSharedSession on the NSB Raven page as this suggests it is the path to go down.
We customise the Document Store in our IoC for migration listeners etc but not the Document Session.
We are using repository classes wrapped around our Raven document sessions - I know about the arguments for and against this but it is the route the team have gone down for now so we are looking at how we can transition to Outbox with minimal changes across the app.
If we get the IoC life cycle correct I’m assuming we can coerce the same DocumentSession into to the repository implementations as the one used on the internal NSB SessionProvider implementation? Or is there some custom config going on within the SessionProvider which means we need to inject that into our repositories rather than the raw document session?
As you are not customizing the session you can just rely on the injected ISessionProvider, not only in your handlers but also in any repository object. As long as those repositories do not have a lifespan that crosses multiple incoming messages, meaning either InstancePerCall or InstancePerUnitOfWork as documented here: