Releases: Particular/NServiceBus.SqlServer
2.2.0
2.1.4
1.2.3
As part of this release we had 142 commits which resulted in 1 issue being closed.
Feature
- #85 Multiple custom schemas support for v1.x
Where to get it
You can download this release from nuget
2.1.3
2.1.2
As part of this release we had 3 commits which resulted in 1 issue being closed.
Bug
- #76 SqlServerStorageContext is not properly registered in the container
Who's affected
All who use SQL Server transport with StructureMap. For other containers only users who wish to access the underlying transport connection or transaction using SqlServerStorageContext class.
Where to get it
You can download this release from nuget
2.1.1
2.1.0
As part of this release we had 6 issues closed.
Bugs
- #44 Invalid header values causing NServiceBus to crash
Features
- #65 Adaptive concurrency
- #66 Using non-default schema on per-endpoint basis
- #62 Programmatically manage connection strings for multi database support
- #57 Moving badly formatted messages to error queue
Improvements
- #7 Make CircuitBreaker intermittent failure delay configurable
Where to get it
You can download this release from nuget
2.0.2
As part of this patch release we had 1 issue closed.
Bugs
- When the endpoints use different database as specified in the connection string, Bus.Reply is not routed properly #59
Who is affected
Any endpoint running on SQLServer transport that is calling Bus.Reply() and using multi-database support via app.config connection string convention.
Where to get it
You can download this release from nuget
2.0.1
As part of this release we had 1 issue being closed.
Bugs
#52 When auditing a reply message, the message is sent to the wrong queue
Instead they are sent to the destination specified in the callback header.
This bug was introduced in v2.0.0
Where to get it
You can download this release from:
2.0.0
As part of this release we had 5 issues closed.
Improvements
#48 Make callbacks and pubsub work seamlessly when scaled out
This is handled by using a secondary receive thread that polls the {endpointname}.{machinename} table. All bus.Reply|Return messages will be sent to this queue to make callbacks work.
#38 Move to .net 4.5
#32 Expose the SqlConnection used to receive incoming messages
This will allow users to reuse that connection if needed to avoid escalating to DTC tx.
The reason for DTC escallation is that even if the connection strings are the same escalation will still happen if more than 1 connection is open at the same time. This will always happen since we need to keep the receiving connection open for the duration of the receive
#3 Improve error reporting in SqlServerPollingDequeueStrategy
raised by @russellchadwick
If you neglect to Configure.Instance.ForInstallationOn<Windows>().Install(), SqlServer transport will not create its tables. Later the SqlServerPollingDequeueStrategy will have exceptions because the objects does not exist.
The issue is that the exception reported to log is
WARN NServiceBus.Transports.SQLServer.SqlServerPollingDequeueStrategy - Failed to connect to the configured SqlServer
The message is inaccurately reporting a connection failure.
migrated from Particular/NServiceBus#1501
Content trimmed. See full issue
Bugs
#29 Using transport with no DTC
This issue is raised as part of the diagnosing of #17
The problem is that to prevent DTC escalation we cannot use nested ADO connections from within a handler, so we need a way to expose both the ado connection + ado transaction to the end user.
Here is what @andreasohlund said:
Did some research and it seems escalation wont happen if "the connections are not open at the same time"
http://stackoverflow.com/a/1693270/236004
Since we keep the connection open during receive I believe the escalation will happen when a second connection is opened. To fix this we need to share the connection or have the users use our native transaction. Does this make sense?
Content trimmed. See full issue
Where to get it
You can download this release from: