-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQL v3: Multi-instance support #139
Comments
We decided to drop the multi-instance support for the V3 of the SQL Transport.
The last one appears to be the most interesting, cause theoretically it enables the transport to work in ServiceControl as well without any change to ServiceControl. We now know that it is not true, actually ServiceControl crashes when using the SQL transport and the multi-instance due to some expectations in ServiceControl not met by the transport, this raises the issue that the transport may have an opinion on the ServiceControl configuration, if we fix this then option (2) is the best in my opinion since from the user perspective an official package is much better than a sample and from our perspective it may end up having a different support life cycle. Along with this decision we also strongly think that we should release a set of guidance on why multi-instance is a bad design decision and how to implement shovel-like solutions in a SQL transport based topology. We think that the async transport task force should only be responsible of:
|
@mauroservienti Till now I've only read multi instance is dropped and not multi database but both are not supported I guess? Lets get our vocabulary straight and use SQL Server terminology:
When saying multi database we basicallly say multi catalog is not supported and that indirectly implies multi instance is not supported too. As I've advocated in #113 I would favor adding catalog and schema identifiers in the queue names. That would make it very easy to support both multi schema and multi catalog while sharing the same / a single connection string. It needs no trickery by defining a schema and/or catalog mapping somewhere as this is the native format of the transport and is readable by any DBA. What would be wrong with supporting fully qualified names name like [Sales]..[OrderProcessing] ? Is such a a queue name too coupled to the transport? Is it that we only want to use 'logical' queues and not physical? |
@ramonsmits we never had a distinction between multi-instance and multi-database, but I think that could be interesting to support the multi-database scenario. @tmasternak thoughts? |
@mauroservienti No I understand as previously we had the mindset to only access a single database on a sql connection (string) but that is restriction we set ourselves. |
I think that I makes sense to support this. On a technical level what @ramonsmits proposes should not be a problem. I need to verify if we can do it in backwards compatible way but I think it should work. @mauroservienti: should I create an issue for that. It can probably be just a spike to figure out if we can do it later for 3.1. |
Yes let's create a separate issue and consider it for the next minor. |
I'm still working on extension point PR. Should be ready this week. |
This is work in progress. We are working on legacy multi-instance code sample //cc: @justabitofcode |
I've cleaned up the issue removing the non-core v6 items. |
Regarding "Documentation/Guidance around security" I think that should be raised as a separate issue in docs. It's not specifically V6 related. |
We are waiting for doc PR to get merged and this one is done. |
@tmasternak can u link to the docs PR |
@SimonCropp I've added PoC for the docs issue that is already linked (the only outstanding in PoC here) |
Will this be included in the retrospective we already scheduled? |
@mauroservienti Of course, that was part of that bigger task & the same TF, so I think we should do it together. |
According to today's discussion - I'm reopening this issue for retrospective. |
Removing the |
Currently we have users who use the multi-instance / multi-catalog support. |
Task force: @tmasternak @weralabaj @justabitofcode @mauroservienti @SzymonPobiega
Summary
We decided to drop the multi-instance support for the V3 of the SQL Transport.
Given that this is a feature that many of our customers could be using, we want to provide our existing users with a proper migration path.
We actually have a working spike that enables the multi-instance support as it was in V2, we decided to ship it as a sample in our documentation.
Along with this decision we also strongly think that we should release a set of guidance on why multi-instance is a bad design decision and how to implement shovel-like solutions in a SQL transport based topology.
Plan of Attack
Queue Schema=
in Connection String for Sql Transport DocumentQueue Schema=
in Connection String for Sql Transport docs.particular.net#1304Update exception message ttps://github.com/Particular/NServiceBus.SqlServer/blob/develop/src/NServiceBus.SqlServer/Legacy/MultiInstance/LegacySqlServerTransportInfrastructure.cs#L51After recent changes in doco we don't need to change it, it's consistent with vocabulary used in doco (comment by @weralabaj)Documentation/Guidance around security ??Moved to Guidance content on security in SQL Server transport docs.particular.net#1347.Related to #100
The text was updated successfully, but these errors were encountered: