Remove the dependency on the DTC when using the multi schema feature

[mauroservienti]

Actually in V2 to enable multi-schema the user needs to define multiple connection strings causing the transport to require the DTC. When using multi-schema we should remove this requirement.

Inception: https://github.com/Particular/CustomerSuccess/issues/166

[ramonsmits]

Basically, make use of fully qualified table names containing catalog + schema to make use of connection sharing.

[SzymonPobiega]

I don't think this is true. When using code API you should be able to specify the schema name and this code: https://github.com/Particular/NServiceBus.SqlServer/blob/master/src%2FNServiceBus.SqlServer%2FSqlServerMessageSender.cs#L36 would get the connection used for receiving the message and use schema-qualified table name.

[mauroservienti]

@SzymonPobiega

I don't think this is true.

Sorry, what's not true?

[SzymonPobiega]

@mauroservienti

Actually in V2 to enable multi-schema the user needs to define multiple connection strings causing the transport to require the DTC

I think you can use a single connection string and configure schema in code in V2.

[mauroservienti]

@SzymonPobiega

I think you can use a single connection string and configure schema in code in V2.

Yes, correct, however it doesn't work in ServiceControl.

[SzymonPobiega]

True :-(

[mauroservienti]

Here is the issue related to ServiceControl, we appraciate your input.

[SzymonPobiega]

So if I understand V3 correctly (cc @tmasternak ), the address string in V3 contains the schema name so when we upgrade SC to NSB 6, it should work automatically. It would be hard to fix in NSB 5.

[tmasternak]

@SzymonPobiega correct.

[tmasternak]

I think that this one is closely related to #156. I think it's worth checking of the effort here. I can create a spike issue that will enable us to figure out how much work is needed and decide to do it or not. Thoughts?

[mauroservienti]

@tmasternak don't we support the legacy mode exactly to address @SzymonPobiega concern about wire compatibility?

[tmasternak]

don't we support the legacy mode exactly to address @SzymonPobiega concern about wire compatibility?

@mauroservienti Do you mean representing addresses with schema on the wire?

[mauroservienti]

No, say that we have a multi-schema based environment. Where V6 needs to talk to V5, V6 address is something like destination@schema V5 will use the old approach, even if V6 sends the reply address as sender@schema V5 can use it since the V5 transport will ignore the thing following the @. Correct?

[tmasternak]

@mauroservienti that is correct.

[tmasternak]

This is connected to #156. Should I close this one and we can track progress there? /cc: @mauroservienti

[mauroservienti]

yeah, replaced by #156