The SQL Server transport is built on top of ADO.NET and will use connection pooling. This may result in the connection pool being shared by the transport, as well as other parts of the endpoint process and the business logic.
In scenarios where the concurrent message processing limit is changed, or the database connection is used for other purposes as mentioned above, it is advisable to change the connection pool size to ensure it will not be exhausted. See also SQL Server Connection Pooling and Configuration.
Connection string can be configured in several ways:
By adding a connection named
NServiceBus/ in the
<configuration> <connectionStrings> <add name="NServiceBus/Transport" connectionString="Data Source=instance; Initial Catalog=db; Integrated Security=True"/> </connectionStrings> </configuration>
By using the
ConnectionStringName extension method:
var transport = configure.UseTransport<SqlServer>("MyConnectionString");
Combined this with a named connection in the
connectionStrings node of the
<configuration> <connectionStrings> <add name="MyConnectionString" connectionString="Data Source=instance; Initial Catalog=db; Integrated Security=True; Queue Schema=nsb"/> </connectionStrings> </configuration>
In multi-catalog and multi-instance modes additional configuration is required for proper message routing:
- The sending endpoint needs to know the connection string of the receiving endpoint.
- The replying endpoint needs to know the connection string of the originator of the message for which the reply is being sent
- The subscribing endpoint needs to know the connection string of the publishing endpoint, in order to send subscription request.
- The publishing endpoint needs to know the connection strings or all the subscribed endpoints
Connection strings for the remote endpoint can be configured via
app. convention. The endpoint-specific connection information can be discovered by reading the connection strings from the configuration file with
NServiceBus/ naming convention.
Given the following mappings:
<UnicastBusConfig> <MessageEndpointMappings> <add Assembly="Billing.Contract" Endpoint="billing"/> <add Assembly="Sales.Contract" Endpoint="sales"/> </MessageEndpointMappings> </UnicastBusConfig>
and the following connection strings:
<connectionStrings> <add name="NServiceBus/Transport" connectionString="Server=DbServerA;Database=MyDefaultDB;"/> <add name="NServiceBus/Transport/Billing" connectionString="Server=DbServerB;Database=Billing;"/> </connectionStrings>
The messages sent to the endpoint called
billing will be dispatched to the database catalog
Billing on the server instance
DbServerB. Because the endpoint configuration isn't specified for
sales, any messages sent to the
sales endpoint will be dispatched to the default database catalog and database server instance. In this example that will be
MyDefaultDB on server
SQL Server transport uses
dbo as a default schema. Default schema is used for every queue if no other schema is explicitly provided in transport address. That includes all local queues, error, audit and remote queues of other endpoints.
The default schema can be overridden via the connection string, using
Queue Schema parameter:
<connectionStrings> <add name="NServiceBus/Transport" connectionString="Data Source=instance; Initial Catalog=db; Integrated Security=True; Queue Schema=myschema"/> </connectionStrings>
A built in circuit breaker is used to handle intermittent SQL Server connectivity problems. When a failure occurs when trying to connect, a circuit breaker enters an armed state. If the failure is not resolved before the configured wait time elapses, the circuit breaker triggers the critical errors handling procedure.