NSB 5 + Raven + MSMQ - When moving to Outbox shouldn't we be using a shared document session?

msmq
nservicebus

(Edward Dewe) #1

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?

I would assume that this means we should be leveraging the ‘Shared Session’ called out in this page: https://docs.particular.net/persistence/ravendb/?version=raven_3

But this does not seem to work - the UseSharedSession config option seems to be broken when used with Outbox and/or Sagas… I think this unfixed ‘Issue’ confirms this: https://github.com/Particular/NServiceBus.RavenDB/issues/71

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?

Thanks in advance.

Edward


(Edward Dewe) #2

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.

Kind regards,

Edward


(Ramon Smits) #3

Hi Edward,

I’ve tested the RavenDB simple sample:

I just enabled Outbox via the code API and added <add key="NServiceBus/Outbox" value="true"/> to a newly created config file.

In the sample you’ll find a handler where a ISessionProvider is injected and used:

I did not have to call UseSharedSession and the shared session works as expected.

However, if I also call UseSharedSession when using Outbox is doesn’t work as mentioned in that linked issue.

Do you need to customize the session?

Regards,
Ramon


(Ramon Smits) #4

Edward,

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.

Regards,
Ramon


(Edward Dewe) #5

Hi Ramon,

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?

Cheers,

Edward


(Ramon Smits) #6

Hi Edward,

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:

Based on the outcome of that reopened issue the documentation will likely be updated.

Regards,
Ramon