Async/Await support

[danielmarbach]

Task force: @tmasternak @weralabaj @justabitofcode @mauroservienti
Make changes to Sql Transport that will make it possible to use it with NServiceBus v6

Impact assessment

Any user who uses sql transport and will want to migrate to v6.

Plan of Attack

• Features
  • Transactions support (done)
  • Multi-database support
  • Multi-schema support (done)
  • TTBR (done)
  • Auto-creation of db structure (done)
• Testing
  • Acceptance tests from core, SqlTransport v2 and new for v3 (done)
  • Performance testing (out-of-scope)
  • Wirecompat test (done)
  • Callback receivers (done)
• Documentation
  • Smoke tests for doc content
  • Upgrade guide SQL Server transport v3: Upgrade guide docs.particular.net#1195
  • Multi-schema v3 to v1/v2 setup guide (not relevant anymore)
  • Connection pool guidance
  • Update docs (done)
  • Update samples : need to be updated and tested after related bugs are resolved- V6 Timeouts do not work with Outbox NServiceBus#3499, NHibernate TimeoutPersister increases chances of getting Concurrency exception in TimeoutDispatcher NServiceBus.NHibernate#161 (done).
• Doco multiinstance https://github.com/Particular/NServiceBus.SqlServer/pull/161/files#r53755702
• Async review @danielmarbach

Related known issues:

• Multi-database setup physical address automatic (connection-string) management
• Wire-compat tests(solved)
• Message id format (solved)

Connects to Transports for v6

[weralabaj]

@mauroservienti @justabitofcode is there anything I could do to help you with pushing multi-db/mulit-instance forward (code, docs, whatever...)?

[danielmarbach]

@Particular/transport-maintainers since all outstanding issues are tracked should we close this one?

[tmasternak]

@weralabaj I think we need to track retrospective somewhere else. Are we tracking sample updates separately in docs?

[mauroservienti]

I think we need to track retrospective somewhere else

why? we tried that and get back to include the retrospective in the original issue

[tmasternak]

@mauroservienti The reason why in my opinion it makes sense to move work left out of this one and close it is visibility. Right now when I look at the issues in repo I already skip this as it brings no value in terms of figuring out what's left. The assumption was if this is colsed we are ready for V6 but we can equaly state that if there is no issue with V6 label we are done.

[weralabaj]

The only thing that is not finished is related to multi-db, we track it with a separate issue.
I'm ok with whatever is more convenient for squad, we can schedule retro now and close it?
I think we won't wait for the v3-v2 pub sub bug right?

[tmasternak]

I think we won't wait for the v3-v2 pub sub bug right?
👍

[mauroservienti]

I disagree 😄, but seems that I'm the minority. So let's close this and open an issue for the retrospective. Are we going to have a retrospective for the v3-v2 pub sub bug?

[weralabaj]

@mauroservienti I think we should discuss it during this retro too. Even if we don't have a fix yet.

[weralabaj]

I've scheduled retro. Closing this issue.

[mauroservienti]

Why are we closing the issue if the retrospective is not happened yet?
Are all the doco stuff done?

[tmasternak]

@mauroservienti sorry for misunderstanding. But what I thought is that we don't want to keep this one around when we have other issues that cover PoA from this one.

[mauroservienti]

Wasn't this behaving as an umbrella for dependent task?
Didn't the squad this morning decided that umbrella issues must be updated with details of the on going progress in dependent tasks?

[tmasternak]

@mauroservienti My understanding was that the decission was: "If the umbrella task exists ... "

[mauroservienti]

OK, got it.

[weralabaj]

@mauroservienti I closed that issue last week, so it might conflict with the decision from today's morning :) We can reopen it if needed, the confusion we wanted to address was having the same thing tracked in multiple issues.
Retro is scheduled for next week.